Documentation
Connecting your tools (MCP / OAuth)
An assistant that can only talk is useful; an assistant that can do things is a product. bmai lets bro call your tools — through your own MCP server — so it can look things up and make changes in your systems, on behalf of your users, under rules you set.
MCP (the Model Context Protocol) is an open standard for exposing tools to an AI. If your systems already speak MCP, bro connects to them the same way it connects to anyone's — no bmai-specific glue.
How bro acts on your users' 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 user 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 users a request is for.
- Your server enforces the scope. Because your MCP knows the user, it returns and changes only that user's data. bro never sees more than your server hands it.
Permission tiers
Every tool you expose is assigned a tier, so the assistant can only reach what's appropriate for who's asking:
| Tier | Who it's for | What it allows |
|---|---|---|
| Public | Anyone, including guests | Safe, non-personal reads — product info, general help. |
| Identified | A signed-in user | Reads and actions on their own data only. |
| Delegated | A signed-in user, for actions that need their authorization | The same, for operations you want explicitly user-authorized. |
| Confirm | Any writing action you mark | The user must confirm before it runs — the full action is shown first. |
Destructive or sensitive operations are held behind confirm: bro surfaces exactly what it's about to do and waits for a human "yes." Nothing writes silently.
Setting it up
Connecting your MCP is done with our team during onboarding today — your server is registered, its tools are classified into the tiers above, and the connection is verified before it goes live. That keeps a powerful capability correctly scoped from day one. See Getting started.
Rolling out: users connecting their own accounts
There's a further mode on the way: per-user OAuth delegation — where each of your users authorizes their own third-party account (via standard OAuth), so bro acts with that user's own grant against a service you don't run yourself. The plumbing is built and standards-based (OAuth 2.1, PKCE, per-user tokens), and it's being switched on carefully behind a security review.
Honest status. Per-user OAuth delegation is not yet available for white-labels — it's in staged rollout, gated on a security sign-off. What works today is connecting your MCP server with the signed-identity model above, which is exactly how our live partner assistants already run. We'll mark this page live the moment it ships.
Next
- Getting started — where your MCP is connected.
- Governance & model policy — enable tools and set confirm rules.
- The assistant experience — how actions appear to a user.