An MCP server exposes capabilities — tools, resources, prompts — over the Model Context Protocol. Connecting one to a sub-agent grants access to that server's entire tool catalog in a single step, rather than defining each tool by hand.
Server vs. individual tool
Both give a sub-agent something to call, but they differ in maintenance cost:
| MCP server | HTTP tool | |
|---|---|---|
| Setup | One connection, whole catalog | One definition per action |
| Schema | Supplied by the server | You define it |
| Updates | Server adds a tool, agent gets it | You add the definition |
| Best for | Existing systems with an MCP server | One-off webhooks, internal APIs |
Connecting one
A connection is defined by its transport (SSE or Streamable HTTP), its endpoint, and its authentication mode. Anter supports testing a connection before wiring it into an agent — worth doing, because a server that authenticates at connect time but fails at call time produces confusing run-time failures rather than a clear setup error.
Connections are managed at the organisation level, then assigned to the projects whose agents should use them.
Scoping and isolation
MCP tool calls execute in the context of the organisation that owns the run, not the organisation that authored the agent. This matters for any agent shared across tenants: the tool acts on behalf of the caller's data, not the author's.
Permissions still apply
Connecting a server does not bypass the permission model. Each tool call from an MCP server is still resolved to allow, ask, or deny before it executes, and a destructive tool will still require approval unless the agent's mode or an explicit per-tool override says otherwise.