Tool servers
Connect a third-party MCP server once, then govern each of its tools with the same roles, risk levels and approvals as your own data.
Your agents are not limited to your own tables and endpoints. Connect a remote MCP server (a payments service, an issue tracker, a document store) and its tools become available to your apps, governed exactly like everything else: a role must grant each tool, each tool has a risk level, and a risky call halts for a person. Nothing a server advertises becomes usable until you review it.
Three gates
A tool from an outside server is usable only when all three of these allow it, and each is checked again on every call:
| Gate | Where | What it decides |
|---|---|---|
| Review | Integrations › Tool servers, organization-wide | Whether a tool is switched on at all, and its risk level. |
| Binding | App integrations › Tool servers, per app | Whether this app can use the server, under which alias, and which of its tools. |
| Policy | A role in the app | Who may call it: the action mcp_<alias>:<tool>. |
So the same server can be bound to two apps under two aliases, with different tools in each, and a policy in one app means nothing in the other. Unbinding the server from an app, or switching a tool off, takes effect on the next call even if a policy still grants it.
Connect the server
In Integrations › Tool servers, choose Connect an MCP server and give its URL, its transport and how it authenticates:
| Transport | |
|---|---|
| Streamable HTTP | The current MCP transport. Recommended. |
| Server-sent events | The older two-channel transport, for servers that only speak it. |
| Authentication | |
|---|---|
| Bearer token | A token sent as Authorization: Bearer …. |
| API key in a custom header | A key sent in a header the server names. |
| OAuth | Approve access in a popup. For a provider that does not register clients automatically, create an app in its dashboard and enter its client credentials under Set OAuth client first. |
| No authentication | A public server. |
Connecting registers the server only. A credential is entered separately, stored encrypted and never shown again. It is deliberately not something an agent can supply.
Connect any server reachable over HTTP; a server that runs as a local process connects through an HTTP bridge. Addresses on private or internal networks are refused.
Review its tools
Sync tools reads the tools the server advertises, and Review tools lists them. Every tool
arrives switched off, with a starting risk level guessed from its name and set to high when it
cannot be classified. For each tool you want:
- switch it on, which only makes it available to bind to an app;
- set its risk level:
lowruns without approval,moderateandhighpause for it.
What a server says about its own tools (that one is read-only, say) is treated as a hint and never trusted for an approval decision. The level you set is what decides.
Bind it to an app
In the app, open App integrations › Tool servers, bind the server under an alias, and choose
which of its enabled tools this app may use. The alias becomes part of each tool's policy action,
so pick a short, stable name such as billing or tracker.
Grant it to a role
Choose Grant to roles on the binding, or add mcp_<alias>:<tool> to a policy on the
Policies page. An agent holding that role now has the tool, and a key for that agent reaches
it over REST and MCP.
Who can use a bound tool
The same tool, under the same policy action, reaches three doors:
- Agents, as a tool in their toolbox. When an app has more than 25 granted tool-server tools,
they are found through
findCapabilityrather than listed every turn. See Tools. - Your handlers, through
sdk.mcp.<alias>. See the SDK reference. - Outside agents connected to your app's own MCP server. Their tools carry
_metaauthoric.ai/external: trueandauthoric.ai/mcpServernaming the alias.
Arguments are checked against the tool's own schema before anything is sent. What comes back is treated strictly as data: the agent is told it came from an outside server and must never follow instructions in it. A very large result is cut off at a size limit, with a marker saying so.
When a server changes
Sync tools again whenever the server's tools may have changed:
- A new tool arrives switched off, like the first time. Connecting a server never quietly widens what your agents can do.
- A changed tool is flagged for review. It keeps working, and its arguments are still checked against the schema you last reviewed.
- A missing tool is kept in the record but refused (
MCP_TOOL_DRIFTED), so its history still reads correctly.
Editing a connection's address or authentication keeps every review and every app binding. Removing and re-adding it does not.
Errors
| Code | When |
|---|---|
MCP_NOT_GRANTED | The app has no binding for this alias, or the binding does not include this tool. |
MCP_TOOL_DISABLED | The tool is switched off in review. |
MCP_TOOL_DRIFTED | The server no longer advertises the tool. |
MCP_ARGS_INVALID | The arguments do not match the tool's schema. |
MCP_TOOL_ERROR | The server ran the tool and reported an error. |
MCP_CONNECTION_FAILED | The server could not be reached. |
MCP_OAUTH_REAUTH_REQUIRED | The connection's OAuth access has lapsed. Approve access again. |
MCP_DISPATCH_CONCURRENCY_LIMIT | Too many calls are already in flight to this server. Retry after Retry-After. |
The concurrency limit is per connection, so one busy caller cannot flood an integration the rest of your organization depends on.