Technical explainer
Most agent platforms can use MCP servers. Far fewer can be one. If you are building a setup where Olano is a component rather than the whole system - an agent that Claude, ChatGPT, Cursor, an automation tool or another company's agent can call - this page covers how an agent becomes a tool or an agent card, what the caller sees, and the part that matters more than the wiring: what happens when a stranger asks it to do something.
Interoperability has a direction. The familiar one runs into the agent: you connect an MCP server and your agent gains its tools. Olano does that, and it is documented under channels and connectors. This page is about the other direction - the agent being the thing that gets called.
Two open protocols cover it. The Model Context Protocol is how an application hands tools to a model; publish an agent over MCP and any MCP client sees it as a tool it can call with a message. The Agent2Agent protocol is how agents find and message each other; publish an agent over A2A and it advertises an agent card - a small document saying what it does, where its endpoint is and which credentials it accepts - that other agents read before sending work.
Olano supports both, per agent, and both are off until you switch them on. That default is the most important thing on this page, so it comes first.
Nothing is reachable from outside unless two separate switches agree. The first is deployment-wide, under Config → External access: serve the MCP endpoint, serve the A2A endpoints, or both. With either off, that surface answers not found to everyone, whatever an individual agent says. The second is per agent, on that agent's External access tab: reachable over MCP, reachable over A2A. An agent that has not opted in is invisible to callers even when the deployment-wide door is open.
Both surfaces also require the deployment to have an https public address - a deployment-wide setting that is on by default. A plain-http endpoint is refused, because the caller's token travels in a request header and would otherwise cross the network in the clear. Loopback and private-network addresses are exempt, for local development only.
Two switches rather than one because they answer different questions. The deployment-wide one is a policy decision an owner makes once: is this deployment the kind of thing outside systems may talk to at all. The per-agent one is a product decision: this particular agent, with this particular description, is fit to be called by a stranger. Keeping them apart means closing the whole deployment is one action, and publishing an agent by accident would take two deliberate ones.
An MCP client that connects sees a tool list: one tool per published agent, named after the agent, plus a tool that lists which agents are available. Calling it sends the agent a message and returns the reply; passing the thread identifier on the next call continues the same conversation, so a remote model can hold a multi-turn exchange rather than starting from nothing each time. An A2A client reads the agent card at the well-known address under the agent's endpoint and sends messages to the JSON-RPC address the card declares; the card also declares which credential schemes the endpoint accepts, including the sign-in flow described below.
What the caller does not see is the agent's system prompt, its files, its configuration, or any other thread. Beyond the agent's name, the only text describing it that leaves the deployment is the public description.
The description is compulsory. A configuration that turns either switch on without one is refused, because publishing an agent with no account of what it does hands a remote model a tool it cannot reason about.
It becomes the MCP tool description and the A2A card description, which makes it the entire basis on which someone else's model decides whether to call your agent and what to send it. It is written for a stranger: one to three plain sentences on what the agent can do for an outside caller, what it needs from them, and what it will not do. It is not the system prompt and is never shown to the agent itself.
That separation is deliberate and worth keeping in your head. The system prompt tells your agent how to behave. The description tells someone else's agent when to bother yours. Reusing one for the other either ships your internal instructions to the world or leaves a remote model guessing at scope - and a model that guesses at scope sends your agent requests it was never meant to take.
Both are managed from the same place; pick by whether the client can paste a header.
| Aspect | Minted token | OAuth sign-in |
|---|---|---|
| Suits | Server-to-server clients, scripts, and any application that can send a bearer header. | Clients that cannot paste a header - a Claude.ai custom connector, an A2A client following the card. |
| How it is issued | An administrator mints it on the agent's External access tab or the fleet view under Config: a label, the agents it may reach (or every exposed agent), a lifetime. | The client discovers the deployment's own authorisation server, registers itself, and sends a person to the dashboard's consent page. An administrator sees who is asking and which agents they requested, ticks the agents to grant, and allows or declines. |
| What is issued and kept | The token is shown once. Only a hash is kept. | A short-lived access token and a rotating refresh token. Authorisation codes are single-use. |
| Reach | Only the agents it names, and only while they are published. | Only the agents ticked on the consent page, and only while they are published. |
| Revoking | From the same list, at any time. | Each registered application has a Forget button that revokes everything it holds. |
| Where it shows | The token list, with its label. | The same token list, tagged OAuth, plus the OAuth clients list. |
Olano runs its own OAuth 2.1 authorisation server for this, rather than borrowing a third party's. The consent page is the load-bearing part: registration grants nothing, and neither does discovery; only an administrator ticking agents on that page does. A client that registers itself and never gets past consent holds no access to anything.
If your organisation already has an identity provider, the endpoints can accept its access tokens instead of, or alongside, the built-in sign-in - bound to this deployment as the audience, with per-agent scopes deciding reach. That is configured on the same Config page.
Publishing itself is administrator-only in every direction. From the dashboard, the External access tab and the Config page are admin surfaces. From chat, an agent can flip its own external access, or send an administrator a page on which a token is minted - the token appears on that page, never in the chat - and it refuses anyone else: a peer agent, a scheduled run, an inbound caller, a member without admin rights, each with an explanation rather than silently. Every route asks the same question, whether the person on this turn is an administrator, and refuses when the answer is no.
This is the part most integrations get wrong, and the reason the safety posture is more interesting than the protocol support. When a call arrives over MCP or A2A, it runs as a normal turn on a thread named after the caller - but as an outside, non-owner caller. The agent's own approval rules apply exactly as they would for anyone who is not its owner.
So if the agent is configured to ask before sending email, moving money or writing to an external system, a request for any of those from an outside caller does not run because a stranger asked. It waits in the Approvals inbox, and the call is held for as long as it waits: the caller gets nothing back until a person on your side has decided. Low-risk work - answering a question, reading something the agent is allowed to read - goes through without a pause, which is what makes the surface usable at all.
The same turn cannot reach anything a caller was not granted. A token reaches only the agents it names. The caller never sees the agent's configuration, files or other threads. And the endpoints check each request's host header against the deployment's public address - the standard defence against DNS rebinding - so a request arriving under a name the deployment does not answer to is refused before it reaches an agent.
The practical consequence is that you can publish an agent to a partner or a tool you do not fully trust and still know the outer edge of what a call can cause: at most, whatever that agent may do without approval, plus a queue entry for everything else. The approvals and trust docs cover how those categories are set per agent.
Your agent can also call agents hosted elsewhere over A2A. The rules are as strict in that direction.
Each agent carries a list of remote agents it may reach: a short name, a base URL, an authentication mode, a credential held in the vault. The agent can only address names on that list. There is no URL parameter, and it cannot add entries itself. An empty list, the default, means it can reach no external agent at all.
The configured URL and the endpoint the remote card advertises are both checked against the same outbound-request policy as every other web tool: https only, no private networks, no cloud metadata addresses. By default the card's endpoint must also share an origin with the URL you configured - a per-entry setting - so a compromised card cannot redirect your credential somewhere else.
Each reply is treated as text from another organisation. Your agent reports what came back rather than following instructions embedded in it, and it is told not to forward secrets or private data you did not ask it to share.
A message to a remote agent counts as an external write for approval purposes, so an agent at the Supervised or Locked-down trust level asks before sending. Reading a card that is not on the list is off by default too, and sending is never ad hoc in any mode.
Everything that crosses the deployment boundary is recorded, in both directions, and kept apart from your agents' own conversations with each other. The Agent to Agent view has an External segment: an outside system asking one of your agents shows the caller by the label of the token or sign-in it used, with an MCP or A2A badge and a globe in place of an agent avatar; your agent calling a remote agent shows the remote by its configured name with an A2A badge. Open a row to read the full exchange.
The same conversations sit in the agent's Chat history carrying an External pill plus the protocol pill, and the agent's External access tab lists its most recent inbound calls with links to both. Nothing an outside caller does is invisible to the people who own the agent, and nothing they do is mixed in with the threads your own team runs.
Both can be on for one agent. The choice follows the caller.
A chat product, a code editor, an automation tool or an agent framework that speaks MCP wants tools. Your agent appears in its tool list as one tool it can call with a message, and a thread identifier carries the conversation across calls.
A partner's agent, or one on another Olano deployment, wants to discover what yours can do before sending work. The agent card gives it that, and the JSON-RPC endpoint takes the message. Each call is recorded as a task the caller can look up afterwards through the protocol's task lookup, for as many days as you choose to keep them.
The description is shared, the credentials are shared, and the approval rules are identical. Two doors, one agent, one set of consequences.
Yes, once an administrator publishes it. An agent can be exposed as a tool on the deployment's MCP endpoint, as an A2A agent card with a JSON-RPC endpoint, or both. Both are off by default at the deployment level and again per agent, the deployment must have an https public address, and every caller needs a minted token or an OAuth sign-in that an administrator has approved on a consent page.
A small published document, at a well-known address under the agent's endpoint, that describes what the agent does, where to send it messages and which credentials it accepts. Agents that speak the Agent2Agent protocol read the card before sending work. On Olano the card's description is the agent's public description, which is written for outside callers and is not the system prompt.
Switch on the MCP endpoint under Config, then open the agent's External access tab, switch on reachable over MCP, write the public description, and save. Mint a token for the client, or let it sign in with OAuth through the consent page. The tab shows the endpoint address and the tool name the client will see. A client that connects sees one tool per published agent plus a tool that lists them.
Whatever that agent is allowed to do without approval, and nothing more. Every inbound call runs as an outside, non-owner caller, so the agent's approval rules apply: anything configured to need a human waits in the Approvals inbox, the call is held until someone decides, and the caller never sees the agent's configuration, files or other threads. A token reaches only the agents it names, and only while they are published.
Yes, over A2A, but only agents listed by name in its own configuration. There is no URL parameter, the agent cannot add entries itself, and an empty list means it can reach nothing outside the deployment. The configured URL and the remote card's endpoint are both vetted, credentials come from the vault at call time, replies are treated as input rather than instructions, and sending counts as an external write for approval purposes.
No. Delegation between agents on the same deployment is separate and unaffected. External calls are recorded under their own segment in the Agent to Agent view, with MCP or A2A badges, and never mixed in with peer conversations.
Where to go next.
The inbound direction - connecting servers to an agent - and why the connections lapse.
The trust levels and approval categories an outside caller runs under.
Adding MCP servers to an agent, the direction most platforms support.
Isolation, the credential vault and the audit trail the external surfaces sit on.
Checked 14 September 2026. Which third-party products speak MCP or A2A, and how they handle sign-in, is their documentation to state and changes over time; the protocol links above are the primary sources. If we have described something wrongly, write to support@olano.ai and we will correct this page.
Tell us what sits on the other end - a custom connector, an automation tool, a partner's agent - and we will say plainly what it will see, what it can ask for, and which of those requests will wait for a person on your side.
