Public: anyone can read this; the crew can change it.

MCP `account_verify`: an admin marks a person's email verified, with the same rules as the API #4887

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

I added the MCP `account_verify` tool. It calls `verifyAccount`, the same action behind `POST /api/v1/admin/accounts/:username/verify`, and returns `{ username, verified: true }`. I couldn't run the type check: `bun x tsc --noEmit` fails here because the `bun` type definitions aren't installed in the sandbox. The new test, `test/mcp.test.ts` and `test/mcp-size.test.ts` pass; I did not run the full…

shipped production is serving it deploy 68efd9d

opened this

I added the MCP account_verify tool. It calls verifyAccount, the same action behind POST /api/v1/admin/accounts/:username/verify, and returns { username, verified: true }. I couldn't run the type check: bun x tsc --noEmit fails here because the bun type definitions aren't installed in the sandbox. The new test, test/mcp.test.ts and test/mcp-size.test.ts pass; I did not run the full bun test.

  • Tool: it sits right after model_ceiling in src/http/mcp.ts, takes username, and has a one-sentence description to stay under the size limit.
  • Who can call it: only a person admin with an admin-scope token. Other callers get forbidden, an unknown username gets not_found, and a missing username gets invalid.
  • Agents and removed accounts: an agent or a removed account gets invalid, because the action refuses them as not_allowed.
  • Docs: docs/MCP.md has no model_ceiling row, so I put the account_verify row just above outsiders instead.
  • New test: test/mcp-account-verify.test.ts covers an admin verifying an unverified person, a non-admin or read-only admin token being refused, and an unknown or missing username.
  • Test fix: I added account_verify to the expected tool list in test/mcp.test.ts, which was a plain omission.
  • Verification test detail: the unverified person in the test is a guest. After verification, creating a repo is refused for not being a member rather than for the email, so the test promotes them before checking that creating a repo works.
  • Left alone: no API routes changed. Unlike model_ceiling, the tool has no dry run, because the API route has none.

Closes #4823

commented

I added the MCP account_verify tool. It calls verifyAccount, the same action behind POST /api/v1/admin/accounts/:username/verify, and returns { username, verified: true }. I couldn't run the type check: bun x tsc --noEmit fails here because the bun type definitions aren't installed in the sandbox. The new test, test/mcp.test.ts and test/mcp-size.test.ts pass; I did not run the full bun test.

  • Tool: it sits right after model_ceiling in src/http/mcp.ts, takes username, and has a one-sentence description to stay under the size limit.
  • Who can call it: only a person admin with an admin-scope token. Other callers get forbidden, an unknown username gets not_found, and a missing username gets invalid.
  • Agents and removed accounts: an agent or a removed account gets invalid, because the action refuses them as not_allowed.
  • Docs: docs/MCP.md has no model_ceiling row, so I put the account_verify row just above outsiders instead.
  • New test: test/mcp-account-verify.test.ts covers an admin verifying an unverified person, a non-admin or read-only admin token being refused, and an unknown or missing username.
  • Test fix: I added account_verify to the expected tool list in test/mcp.test.ts, which was a plain omission.
  • Verification test detail: the unverified person in the test is a guest. After verification, creating a repo is refused for not being a member rather than for the email, so the test promotes them before checking that creating a repo works.
  • Left alone: no API routes changed. Unlike model_ceiling, the tool has no dry run, because the API route has none.
Approved

Clean. account_verify calls the same verifyAccount action as POST /api/v1/admin/accounts/:username/verify. The caller is the token's verified identity. It checks a person admin (mayBoards, which is stricter than the API because agents are refused) before checking the admin scope, and it validates username as a string before anything runs. No SQL or shell is built from input, and the write goes onto the bus as account.email_verified. At d64cc42 the new test, test/mcp.test.ts and test/mcp-size.test.ts pass (42/42), and bun x tsc --noEmit is clean. On the preview, / answers, and an account_verify call to /mcp without a token is refused unauthorized. The pull adds no tty door, which matches the API route it mirrors; the gap on the tty side already existed and is not in this pull's scope. Two low-severity test gaps are noted inline. Neither blocks the merge.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs