Chapter 18: Connecting the @seameet/mcp CLI

The @seameet/mcp CLI is a headless Model Context Protocol server that lets other tools (Claude Desktop, IDEs, agents) read from and write to your SeaMeet account. Because it's headless, you approve it via a device-authorization flow (RFC 8628) — the CLI shows you a short code, you visit a URL, confirm the code, done.

This chapter covers the web-app side: the /link page, the approve action, and the guard rails.

The flow, end-to-end

Run the CLI (e.g. npx @seameet/mcp or a client that spawns it).
The CLI prints a short code and a URL — typically app.seameet.ai/link and a code like ABCD-EFGH.
Open the URL in your browser.
On the /link page, enter the code (or the CLI may pre-fill it via query string).
Click Approve.
The CLI receives a read+write API key on your behalf and can now act.

That's it. The whole flow typically takes under 30 seconds.

What "on your behalf" means

The API key issued by /link is a real per-user token scoped to your SeaMeet account. Anything the CLI does with it appears in your library as your action. Concretely:

Read — the CLI can list your recordings, fetch transcripts and summaries, query Meeting Memory across your archive.
Write — the CLI can create recordings (via upload), update titles and descriptions, create shares, and generally do what your normal session can.

Because the token is bound to your account, revoking your session (sign out everywhere) does NOT revoke the CLI's token — the token is a separate credential. See "Revoking a CLI approval" below.

The /link page requires a real signed-in, verified account. That means:

Signed out. The page redirects you to /signin with a returnTo parameter carrying the code, so after signing in the flow resumes on /link with the code intact.
Anonymous guest session. Same as signed out — the guest session cannot approve a CLI, because the CLI needs a real identity to bind to. You're sent to /signin to promote the session to a real account.
Signed-in and verified. The approve action is enabled.

This is a deliberate guard rail. Without it, a CLI could act "on behalf of" a throwaway anonymous session that no human deliberately opened.

Explicit click-to-approve

The /link page never auto-authorizes. Even when the code is pre-filled via ?code=<value>, you have to explicitly click Approve. This is defensive: an auto-approve on load would be a phishing vector — a malicious page could open /link?code=<attacker's-code> in your browser and mint a token for the attacker before you noticed.

Always verify the code shown on the page matches the code shown by your CLI before clicking Approve. If they don't match, close the page.

The approve action

Click Approve and:

The web app verifies the code with SeaMeet's servers.
The server checks the code is valid, unexpired, and bound to a real (non-anonymous) account.
If valid, it mints an API key, associates it with the code, and returns success.
The CLI, which has been polling the token endpoint, receives the key and prints a success message.
The web app's /link page shows "Approved" — the tab can be closed.

If the code is expired (RFC 8628 codes are short-lived — typically 15 minutes), the CLI must generate a fresh one and start over.

Revoking a CLI approval

Two ways:

From the CLI side. Delete the token in the CLI's local storage (or run the CLI's logout command, if provided). The token remains valid server-side until you also revoke it there.
From the account side. Account → Connected apps → find the CLI approval by its last-use timestamp → Revoke. This invalidates the token server-side immediately.

For the paranoid: revoke server-side. The CLI-side delete just stops the current CLI process from using the token; it doesn't prevent a copy of the token from being used elsewhere.

Multiple CLI approvals

You can approve the CLI multiple times (e.g. once per machine you use it on). Each approval mints a separate API key. Account → Connected apps lists them with per-key metadata (last used, first approved).

Revoking one CLI approval doesn't affect the others.

Token security

The token is stored in the CLI's local config directory, unencrypted by default.
If your machine is compromised, the token is compromised. Revoke server-side and re-approve.
The token has no expiry by default (long-lived). If you want short-lived tokens, revoke and re-approve as your rotation schedule requires.
Tokens are transmitted over HTTPS (HSTS-protected — see Chapter 17).

Entitlement carry-through

The CLI acts as you — so it has your entitlement tier. If you're free-tier, the CLI is subject to the free-tier reveal cap when reading transcripts. Sync Pro? The CLI has full read.

Write actions like creating recordings count against your quotas the same way a normal session would.

Common problems

"The code is expired." Codes are short-lived (typically 15 minutes). Restart the CLI to get a fresh one.

"The code approved but the CLI didn't notice." The CLI polls the token endpoint every few seconds. Give it 10-15 seconds. If still nothing, restart the CLI — it may have crashed the polling loop.

"I signed in and lost the code." The /link page carries the code in returnTo — sign in and you land back with the code preserved. If somehow lost, restart the CLI for a fresh code.

"Approve returns 'not_entitled' error." The account's entitlement doesn't include CLI approval — currently CLI approval requires Sync Pro. Upgrade and retry.

"I approved but my CLI still says 'authorization required'." Check the CLI's config directory for the stored token (path varies by CLI version). If empty, the CLI missed the token — restart and re-approve.

Quick Reference

Task	How
Approve a CLI code	`app.seameet.ai/link` → enter/verify code → Approve
Revoke a CLI token (server side)	Account → Connected apps → Revoke
Revoke a CLI token (client side)	CLI's `logout` command, or delete the CLI config file
See all approvals	Account → Connected apps
Approve on multiple machines	Approve once per machine — each mints a separate token

Last updated: 2026-08-28

← Chapter 17: Account and Settings

Connecting the @seameet/mcp CLI