# Connecting your systems (MCP) | Busymate AI Source: https://busymate.ai/docs/connectors Last modified: 2026-09-04T13:14:52+03:00 MCP (the Model Context Protocol) is an open standard for giving an AI assistant tools. Busymate AI lets bro use your tools through your own MCP server, on behalf of your customers, under rules you set. Each tool gets an access level — open to anyone, signed-in customers, or on the customer's behalf — and every change you mark waits for a confirmation card. Your server learns who the customer is from a signed token it verifies, and returns only that customer's data. If your systems already speak MCP, bro connects to them the same way it connects to anyone's — no platform-specific glue. ## How bro acts on your customers' data When your assistant needs to do something, it calls a tool on your MCP server. Two things make that safe: 1. **bro tells your server who the customer is** — as a short-lived, cryptographically **signed** token your server verifies. It can't be faked or replayed, so your server always knows exactly which of your customers a request is for. 2. **Your server enforces the scope.** Because your MCP server knows the customer, it returns and changes only *that* customer's data. bro never sees more than your server hands it. Diagram: A customer chats with bro; bro calls your MCP server carrying a signed token identifying the customer; your server verifies it and returns only that customer's data ## Access levels Every tool you expose gets an access level, so the assistant can only reach what's appropriate for who's asking: | Access level | Who it's for | What it allows | |---|---|---| | **Open to anyone** | Anyone, including visitors | Safe, non-personal look-ups — product info, general help. | | **Signed-in customers** | A signed-in customer | Look-ups and actions on **their own** data only. | | **On the customer's behalf** | A signed-in customer, for actions that need their say-so | The same, for actions you want the customer to authorize. | | **Confirmation step** | Any change you mark | The customer must confirm before it runs — the full action is shown first. | Changes that matter are held behind a **confirmation step**: bro shows exactly what it's about to do and waits for a yes. Nothing changes silently. ## Setting it up The **Integration** section in your Busymate AI Console is the source of truth for this setup. It is generated from the selected workspace's live settings, so its URLs, sign-in values, snippets, and release checklist stay current — there is no separate handoff document to keep in sync. 1. Open [Console → Integration](https://busymate.ai/console/integration) and select the workspace you are configuring. 2. Follow its MCP step to **Connections**, add your server URL and how it authenticates, then run the probe. 3. Review every tool it finds and set each one's access level and confirmation deliberately. 4. Run the checks and publish. A failed probe or an incomplete sign-in setup blocks publishing, instead of producing a half-connected assistant. The Integration section also gives you a copy-ready brief and the Busymate AI management MCP address for teams that want an AI agent to do the same setup. See [Getting started](https://busymate.ai/docs/getting-started). ### Connect Claude Code to the management MCP One command; the browser handles sign-in with your normal account (OAuth 2.1 — nothing is pasted): ```bash claude mcp add --transport http busymate-ai https://busymate.ai/mcp ``` Then run `/mcp` inside Claude Code and choose **busymate-ai → Authenticate**. Any other HTTP-MCP client (Claude Desktop, Cursor, …) connects with just the URL `https://busymate.ai/mcp` — sign-in is discovered automatically, so no other configuration is needed. ## Customers connecting their own accounts **Each customer can connect their own account** to a service you do not run. Use it when a customer must authorize their own account elsewhere. Set the connection's authorization details in **Connections**, then publish its on-the-customer's-behalf tools. There are two ways the assistant can act for a signed-in customer: - **Automatic (a signed action proof)** — recommended when your product has already verified the visitor. Busymate AI creates a short-lived, workspace-and-connection-bound proof for your MCP server, so account access is automatic and the customer does not see a second sign-in or consent prompt. - **Each customer signs in once (OAuth)** — use this when a separate consent is intentional. The assistant shows **Authorize account tools** once, uses OAuth 2.1 with PKCE, and binds the grant to the workspace, the connection, and the verified customer. Both fail closed. Your MCP server works out the customer only from the verified token, and never trusts an account id passed in a tool's arguments. OAuth grants can be revoked from the account menu; signed proofs expire in at most five minutes and are pinned to one connection. ### Does my server have to speak MCP? Yes — standard MCP over HTTPS, JSON-RPC 2.0, with schemas on `tools/list`. No platform-specific glue. ### How does my server know which customer is asking? From the verified token bro sends: a short-lived signed proof, or a per-customer OAuth token. Never from an account id in a tool's arguments. ### Automatic proof or per-customer OAuth? The signed proof when your product already verified the visitor and you want no second consent. OAuth when a separate consent screen is intentional. ### Where do I set it up? Console → Connections, then run the checks and publish. The steps, the probe and a worked call are in [Connect your MCP server as assistant tools](https://busymate.ai/docs/guides/connect-mcp-server). ## Next - **[Getting started](https://busymate.ai/docs/getting-started)** — where your MCP server is connected. - **[Governance and models](https://busymate.ai/docs/governance)** — turn actions on and set confirmation rules. - **[The assistant experience](https://busymate.ai/docs/assistant-experience)** — how actions appear to a customer.