Connect your MCP server as assistant tools

AI Assistant turns your MCP server into your mate's tools. MCP (the Model Context Protocol) is an open standard for giving an AI assistant tools over HTTPS. Register your server, give every tool one of three access levels, flag the writes that should ask first, choose how your server learns who the customer is, then probe, check and publish. Your server keeps the data; your mate only calls it.

What you build

An MCP server that serves tools/list with input schemas and answers tools/call. The one rule that makes it safe: your server works out the customer only from the verified bearer — never from an account id in a tool's arguments. Every tool gets one of three access levels plus an optional confirmation step; see Connecting your systems for the levels and the Glossary for the words.

1. Expose the server

1. Serve it over HTTPS at a stable URL, reachable from the public internet.
2. Speak JSON-RPC 2.0 over streamable HTTP (http) or server-sent events (sse).
3. Return a name, description and JSON schema per tool on tools/list. Public tools need no bearer; identified and delegated calls carry one.

2. Choose how your server knows the customer

Two ways, one row each:

Both fail closed: no bearer on a delegated call is a 401, and a mismatched workspace or connection is denied.

The actor verifier secret (self-serve)

The signed actor token is HS256. The key your server verifies it with is yours to set — nobody has to hand it to you:

1. Generate a secret: openssl rand -base64 32 | tr '+/' '-_' | tr -d '=' (base64url, at least 32 bytes).
2. Save it on the connection: Console → Connections → Actor verifier secret → Set (set_connector_actor_verifier from your AI tools). The value is write-only; the field shows only "set on <date>" and a masked ending.
3. Install the same value in your verifier — the partner kit reads it from your secret manager — and have your own status endpoint report actorVerifier: true.
4. Set Delegated account access to the signed customer actor token, probe, save.

Rotation. A new secret takes effect at once, and the previous value stays accepted as a retry key for 24 hours — a call your server rejects under the new key is retried once under the old one, so you can roll the secret across your servers without dropping a visitor. The same grace applies to the first secret you set. Clear removes it immediately, with no grace, and any platform-provisioned key applies again.

Identified tools need a mode. With delegated access Off, an identified tool would reach your server with no bearer, so it is never offered. The editor marks those tools "not offered" and upsert_tenant_connector returns them in withheld_tools; pick either mode above to offer them.

3. Server auth

The connection's own credential is none, bearer or oauth. It is stored write-only in Connections and never appears in a tool argument, a prompt or a log.

4. Add the connection

1. Open Console → Connections for your workspace.
2. Enter the URL, the transport and how it authenticates, then run Probe. It fetches tools/list through an SSRF-guarded client and shows every tool it finds.
3. Set each tool's access level — public, identified or delegated — and tick Confirm on every change. An unmarked change runs without a card, so mark deliberately.

From your AI tools the same steps are probe_mcp_connector and upsert_tenant_connector; the write shows its payload and waits for your confirmation.

5. Check and publish

Open Console → Release, run the checks, publish. Publishing creates a frozen version (publish_tenant_runtime from your AI tools). A failed probe, an unreachable server or an unsafe rule blocks the release rather than shipping a half-connected assistant.

6. Prove a call on the customer's behalf

Send the call your server will receive, with a bearer of the mode you chose:

// POST https://YOUR-DOMAIN/mcp
// Authorization: Bearer <the per-user OAuth token your mate obtained>
{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": { "name": "get_my_account", "arguments": {} }
}
// Your server verifies the bearer, derives the user from its signed subject,
// and returns ONLY that user's data.

Your server verifies the bearer, works out the customer from its subject, and returns that customer's data — nothing else.

Manage from any MCP client

The management surface is itself an MCP server. Connect once with OAuth 2.1 in the browser:

claude mcp add --transport http busymate-ai https://busymate.ai/mcp

Then run /mcp in Claude Code and choose busymate-ai → Authenticate. Any HTTP-MCP client connects with the URL https://busymate.ai/mcp alone.

Troubleshooting

• Probe fails — the URL must be HTTPS, publicly reachable, and answer tools/list.
• 401 on a delegated call — the bearer is missing, or its audience or issuer does not match.
• A tool is not offered — its level is above who is asking: visitors see public tools only, and an identified tool is withheld while delegated access is Off.
• 401 after you rotated the verifier — the old secret verifies for 24 hours, then only the new one. A 401 that persists means your server holds a different value from the connection.
• A change ran without a card — it was not marked as needing confirmation. Mark it and publish again.

Verify

1. Connections lists every tool from tools/list with its access level.
2. A signed-in test customer asks your mate for their account; the call returns that customer's object.
3. A confirm-marked change shows a card with the full payload and runs only after the customer says yes.
4. A visitor cannot reach an identified tool.

Next

• Recognize signed-in customers — the identity delegated tools depend on.
• Connecting your systems (MCP) — the access levels and the confirmation step, explained.
• Build your MCP server — a worked example, as a public page.