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.

Documentation

Connecting your systems (MCP)

English

On this page

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:

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.
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.

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.

Open Console → Integration and select the workspace you are configuring.
Follow its MCP step to Connections, add your server URL and how it authenticates, then run the probe.
Review every tool it finds and set each one's access level and confirmation deliberately.
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.

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.

Getting started — where your MCP server is connected.
Governance and models — turn actions on and set confirmation rules.
The assistant experience — how actions appear to a customer.

Questions

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.