# Connect your MCP server as assistant tools | Busymate AI Source: https://busymate.ai/docs/guides/connect-mcp-server Last modified: 2026-09-04T13:24:41+03:00 Busymate AI turns your MCP server into bro's tools. MCP (the Model Context Protocol) is an open standard for giving an AI assistant tools over HTTPS. You register your server, give every tool one of three access levels, mark the changes that need a confirmation card, choose how your server learns who the customer is, then probe, check and publish. Your server keeps the data; bro 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 it receives — never from an account id passed in a tool's arguments. Every tool you expose gets one of three access levels plus an optional confirmation step; see [Connecting your systems](https://busymate.ai/docs/connectors) for the levels and the [Glossary](https://busymate.ai/docs/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 for every tool on `tools/list`. Public tools need no bearer; identified and delegated calls arrive with one. ## 2. Choose how your server knows the customer Two ways, one row each: | Mode | What bro sends | You verify | Use it when | |---|---|---|---| | Signed actor token | A short-lived platform token (at most five minutes). Issuer `https://busymate.ai`, audience your origin. Subject is the signed-in customer's unchanging id. Workspace and connection are pinned. | The verifier from the partner kit; its key is installed from a secret manager, never argv or source | Your product already verified the visitor and you want no second consent | | Per-customer OAuth | An OAuth 2.1 access token per customer: authorization code with PKCE S256, RFC 8414 / RFC 9728 discovery, RFC 7591 registration, RFC 8707 resource binding, RFC 9207 issuer check | Your own authorization server | A separate consent is intentional | Both fail closed: no bearer on a delegated call is a 401, and a mismatched workspace or connection is denied. ## 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](https://busymate.ai/console/connections) for your workspace. 2. Enter the URL, the transport and how it authenticates, then run **Probe**. The probe fetches `tools/list` through an SSRF-guarded client and shows every tool it finds. 3. Give each tool an access level — public, identified or delegated — and tick **Confirm** on every change. A change you forget to mark 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 full payload and waits for your confirmation. ## 5. Check and publish Open [Console → Release](https://busymate.ai/console/release), run the checks, publish. Publishing creates a frozen version (`publish_tenant_runtime` does the same from your AI tools). A failed probe, an unreachable server or an unsafe rule blocks the release instead of shipping a half-connected assistant. ## 6. Prove a call on the customer's behalf Send the call your server will receive from bro, with a bearer of the mode you chose: {{snippet:delegated-call}} 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: {{snippet:claude-code}} 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's asking: visitors see public tools only. - **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 bro 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. ### Does bro see my customers' data? Only what your server returns for the verified bearer. Your server enforces the scope; bro never receives more than it hands back. ### Can the model pass another customer's id? It can try; your server ignores it. The customer comes from the bearer's signed subject, never from a tool's arguments. ### Signed actor token or per-customer OAuth? The signed proof when your product already verified the visitor — no second sign-in. OAuth when a separate consent screen is the point. ### What happens to a change the customer did not confirm? A tool you mark for confirmation stops at a card showing the exact action. Nothing runs until the customer agrees. ## Next - **[Recognize signed-in customers](https://busymate.ai/docs/guides/identified-visitors)** — the identity your on-the-customer's-behalf tools depend on. - **[Connecting your systems (MCP)](https://busymate.ai/docs/connectors)** — the access levels and the confirmation step, explained. - **[Build your MCP server](https://busymate.ai/artifact/build-your-mcp-server)** — a worked example, as a public page.