The tool gateway — MCP and brokers in one audited interface

Cursor has a GitHub MCP server. Claude has a different one for mail. ChatGPT has a third for Grafana, or a token pasted into the system prompt. Each server answers. Each one also keeps its own secret, its own process, and its own idea of what the team allowed.

That pile is not a platform. It is a desk drawer of MCP servers.

When an agent comments on a pull request, the organization should be able to say who asked, which credential ran, and what came back. When someone leaves, you revoke one install. You do not hunt config files in three products. When a teammate opens another host tomorrow, the same brokers should already be there.

BitsWeave is that layer. The MCP surface is how agents reach the org. Brokers are how the org reaches GitHub, email, Grafana, and the rest. Together they are one tool gateway: a single audited interface. Credentials stay in BitsWeave. The agent acts with tools_call.

This post is the gateway. For how those connections feed shared team context, see MCP connectors and team context.

What a tool gateway is

A tool gateway is the one place an agent authenticates, discovers tools, and acts. Behind that door, the organization holds the credentials and the permission rules.

Ad-hoc MCP servers invert the split. You install a server next to the agent. The token lives in that host's config. The log, when there is one, lives in that process. A second host needs a second copy. A second app needs a second server. Audit becomes "check three dashboards and a terminal."

A gateway keeps the jobs apart:

• The agent holds a credential for BitsWeave, not a credential for GitHub.
• BitsWeave holds the broker install. That is the OAuth grant, the API token, or the webhook secret.
• Every action goes through one interface. The call is authenticated, scoped, and attributed to a member.

The MCP surface is the front of that gateway. Brokers are the back. The surface without brokers is an empty bench. Brokers without the surface are private connectors that the next host cannot share.

The MCP surface is the front door

BitsWeave speaks MCP, the Model Context Protocol. Add the server to the agent you already run. The agent does not receive a flat dump of every procedure in the product.

tools/list is short on purpose. The advertised list is the meta tools — tools_search, tools_get, and tools_call — plus domain seeds for accounts, organization, documents, context, records, and sessions. Broker seeds appear for brokers that are actually installed. Install a broker and its actions show up. Uninstall it and they leave.

Discovery and execution are different steps.

tools_search and tools_get tell the agent what exists. They return dotted procedure addresses, schemas, and whether a broker tool is installed. Seeds on the list do the same job for the domains and installs already in front of the agent.

tools_call is how the agent acts. It takes a procedure address and a JSON input. documents.list and a GitHub diff read go through that same call. The agent does not get a new MCP server when you connect Grafana. It gets another address on the gateway it already trusts.

That short list is the point. A host that advertises hundreds of raw tools on day one is hard to review. A host that advertises a dispatcher, plus the seeds for what this org installed, stays reviewable. Billing and credential-minting procedures stay off MCP. The web app can still do those jobs. The agent does not get a side door to them.

Brokers keep the credentials

A broker is a two-way connector. Events come in. Actions go out.

GitHub can deliver a pull request and let an agent read the diff or post a review. Grafana can deliver an alert and let an agent query metrics. Email can send as the org. A webhook broker can ingest JSON from a system you already run. The shape is the same. The external system talks to BitsWeave. The agent talks to BitsWeave.

Installing a broker is an organization act, not a chat act. An admin connects the external account. BitsWeave stores the credential on that install. There is one install per broker per organization. The agent never receives the GitHub token, the Grafana key, or the mail secret.

Permissions follow the org, not the prompt. Read tools and write tools are different capabilities. A diff read is not a review comment. The same rules apply when a person uses the product and when an agent calls tools_call. Disable an install to pause it and keep history. Uninstall it to drop the credentials and keep the audit trail.

Search can still name a broker the org has not installed. Those rows are not executable secrets. A person connects the app. The agent does not invent an OAuth URL, and it does not scrape a token out of a document.

What tools_call actually does

tools_call is the dispatcher. The input is small.

• procedure — a dotted address from a seed or from tools_search. Examples: documents.list, or a broker operation such as the GitHub pull-request diff.
• input — the JSON object that matches that procedure. Omit it when the tool takes nothing.

The call runs as the authenticated member, in the active organization. BitsWeave resolves the address, checks the permission, and performs the org call or the broker call with the stored credential. The result comes back to the agent. The credential does not.

Failures stay on that path. An unknown address is an error, not a silent guess. A call the role cannot make does not get a second MCP server that someone pasted into the IDE. Underscore aliases still resolve, so an older name does not become a second catalog.

This is also how custom tools and broker tools stay one list. A document query, a skill run, and a GitHub review comment are different procedures. They are not different trust boundaries. For the multi-step shape that uses those calls — plan, tool, check, next step — see agentic workflows.

Ad-hoc MCP servers fail the team in four places

An ad-hoc MCP server is a fair prototype. You want the agent to see GitHub this afternoon, so you run a server beside Cursor and drop a token in the environment. That solves one person's day. It does not survive a team.

Credentials spread. Each server stores a secret where the agent runs. A laptop, a CI box, and a teammate's Claude project each hold a token the org cannot see. Rotation means editing configs. It does not mean uninstalling one broker.

Audit splits. One server logs to stdout. Another logs to a vendor console. A third logs nothing you can attribute to a person. On the gateway, the call is authenticated and attributed: which tool ran, on whose behalf, with the organization's credential.

Catalogs diverge. Cursor's GitHub server, Claude's mail server, and a one-off Grafana server do not share an install list. The BitsWeave surface does. One install, and every connected client sees the same broker seeds. Remove the install, and those seeds leave every host.

Permissions are local folklore. An ad-hoc server often runs with the full token you gave it. There is no org role between "read the diff" and "post the review." The gateway keeps that split. Write tools stay behind write permission.

A local tool can still sit beside the agent. That server is not a substitute for the organization's gateway to the apps the whole team shares.

One interface, then the work

The gateway is how the agent acts. It is not, by itself, the memory of the work.

A review comment posted through a broker should land where the next session can cite it. Documents and records are that place. The context graph is how you walk from a focal record out to the decisions and objects around it. An MCP server that lives inside one host never becomes that shared neighborhood. The gateway is what makes the same broker, and the same record, available when the person moves from Claude to Cursor to ChatGPT.

Gateway versus a pile of servers

	Ad-hoc MCP servers	BitsWeave tool gateway
Where the token lives	The agent's config	The org's broker install
How the agent acts	A different server per app	tools_call on one MCP surface
Who shares the catalog	Whoever copied the config	Every connected host
Uninstall	Edit files, hope you found them all	Drop the credential, keep the audit trail
Read versus write	Whatever the token can do	The member's role
What the next host sees	A new setup	The same brokers

How to tell which one you bought

1. Where does the GitHub token live? If it lives in the agent's config, you have an ad-hoc server. If it lives on an org install, you have a broker.
2. How does the agent act? If each app is a separate MCP process, the catalog will drift. If every action is tools_call on one surface, the catalog is the install list.
3. Can you uninstall, drop the secret, and keep the trail? A gateway can. A token in a dotenv file cannot.
4. Do Claude, Cursor, and ChatGPT see the same brokers? If each host has a private server list, you are copying credentials. If they share the BitsWeave MCP server, they share the gateway.
5. When the agent writes, whose permission is it? If the answer is "whatever the token can do," you skipped the org. If the answer is the member's role, the call is that person's action.

If the answers lean copied tokens, per-host servers, and no trail, you are collecting MCP servers. If they lean one surface, org credentials, and tools_call, you have a tool gateway.

Put the tools behind one door

Stop collecting MCP servers as the integration plan. Add the BitsWeave server once. Install the brokers the team actually uses. Let the agent discover them and act with tools_call. Keep the credentials in the organization, on one audited interface.

The hosts can change. The door does not.

Connect Claude, Cursor, or ChatGPT at bitsweave.com. The brokers stay with the org. The agent calls the gateway.