Book a demo Start free

Product

Product overview Agents Automations Apps Code (Beta) Integrations Governed Runtime Security

Where Renly runs

Windows app Android app Inside other AI apps

Solutions

Finance Sales Operations People and HR Marketing Enterprise

Resources

Pricing Docs Academy Blog Compare Support

AI governance and capability

AI governance framework AI governance assessment AI capability maturity AI maturity assessment
Book a demo Sign in

Lesson 8 of 9 · 10 min read

Protocols: MCP and A2A

Two open protocols now connect the agent world. MCP connects an agent to tools and data. A2A connects one agent to another. Here is how each works and where governance fits.

Two questions every agent has to answer

An agent that only talks to its own built-in tools hits a wall fast. Sooner or later it needs to reach something its builders never wired in: a ticketing system, a database, a design tool. And sooner or later it needs to hand part of a job to another agent, one that someone else built and runs. Those are two different problems, and the industry has settled on two different open protocols for them.

  • How does an agent reach a tool or a source of data? The Model Context Protocol, MCP.
  • How does an agent hand work to another agent? The Agent2Agent protocol, A2A.

Both are now governed in the open under the Linux Foundation, which matters: they are no longer one vendor's format, so the tools you connect today will keep working as the products around them change.

MCP: connecting agents to tools

MCP has three roles. Learn them once and every MCP setup guide becomes easy to read.

  • Host. The application the person is using: a chat app, an IDE such as VS Code or Cursor, a coding agent such as Claude Code, or a platform such as Renly. The host owns the conversation and decides what the model is allowed to do.
  • Client. A connector inside the host. The host runs one client per server it talks to.
  • Server. The program that provides the tools and resources. A GitHub server offers tools such as "create issue"; a documentation server offers resources to read. The server does the work; the host decides whether to ask it.

A session follows the same short script every time. The client sends initialize, and the two sides agree a protocol version and what each supports. The client then calls tools/list to discover the tools, each with a name, a description and an input schema, exactly the kind of tool description you learned to write in lesson 2. When the model wants to use one, the client sends tools/call with the arguments, and the server returns the result. A server can run on your own machine (the stdio transport) or as a remote service over HTTP (the Streamable HTTP transport).

Tools can carry annotations: hints such as readOnlyHint ("this only reads") and destructiveHint ("this can delete or overwrite"). They are useful, but the specification is clear that a host should treat them as untrusted unless it trusts the server. A hostile server could label a delete as read-only. Keep that in mind; it is the heart of MCP governance.

A2A: connecting agents to agents

MCP treats the other side as a tool: a function with inputs and outputs. A2A treats the other side as a peer agent that has its own reasoning, its own tools and its own rules, none of which it has to reveal. You do not call its functions. You give it a task.

Discovery starts with the Agent Card, a small JSON document an agent publishes at a well-known address, /.well-known/agent-card.json. It advertises the agent's identity, its skills, the endpoint to call and how to authenticate, so another agent can find it and decide whether it is the right one for the job.

Work then happens as a task. The calling agent sends a message; the remote agent creates a task and moves it through states. The ones to know:

  • WORKING: the remote agent is on it.
  • INPUT_REQUIRED: the remote agent is paused and needs something before it can continue. This is the state a well-governed agent uses when a human has to decide, for example to approve an action.
  • AUTH_REQUIRED: it needs the caller to supply credentials.
  • COMPLETED, FAILED, CANCELED and REJECTED: the end states. The results come back as artifacts.

The caller can wait for the answer, poll for it with GetTask, or subscribe to a stream of updates. A2A began at Google in 2025, moved to the Linux Foundation, and absorbed IBM's Agent Communication Protocol (ACP merged into A2A) rather than leaving the field with two competing standards. Version 1.0 is the current release.

MCP connects an agent to tools; A2A connects an agent to another agent Left: an MCP host, such as an IDE or Renly, runs one client per server. Each client connects to an MCP server that provides tools and resources. Right: a calling agent reads a remote agent's Agent Card, sends it a task, and the task moves from working to input required, where a person approves, and then to completed. MCP: agent to tools Host IDE, chat app, Renly Client A Client B decides what may run Server: tickets tools: search, create Server: docs resources: pages initialize, tools/list, tools/call A2A: agent to agent Calling agent has a task to hand off Agent Card Remote agent own tools, own rules 1. read card 2. send task WORKING INPUT_REQUIRED COMPLETED a person approves 3. poll, stream or wait for the result
MCP: the host calls tools on servers. A2A: an agent hands a task to a peer and follows its state.

MCP or A2A? A quick test

Ask one question: is the thing on the other side a function or a colleague?

MCPA2A
ConnectsAn agent to tools and dataAn agent to another agent
The other side isA server exposing functions and resourcesA peer that reasons for itself and keeps its internals private
Discoverytools/list after connectingThe Agent Card at a well-known URL
Unit of workOne tool call, one resultA task with states, history and artifacts
Waiting on a personUp to the hostBuilt in: INPUT_REQUIRED

They are complementary, not rivals. A typical setup uses both: your agent uses MCP to reach its tools, and A2A to delegate a whole task to a specialist agent owned by another team or another company.

Worked example: one request, both protocols

A developer at a logistics firm works in VS Code. She has added Renly as an MCP server, so her coding assistant can see Renly's tools. She asks it: "Ask our finance agent whether the Q3 carrier invoices are reconciled, and fix any mismatch."

  1. The assistant (the MCP host) calls list_agents, finds the finance agent, and calls ask_agent. That is MCP.
  2. Inside Renly, the finance agent reads the ledger through its own connectors, finds two mismatched invoices and proposes a correcting entry. Correcting the ledger changes data, so it waits for approval.
  3. The tool result says so plainly: waiting for approval in Renly, with a link. The assistant cannot approve on her behalf. No tool on Renly's MCP server can.
  4. She opens the link, reads the proposed entry, approves it, then asks the assistant to check again. It calls get_conversation and gets the finished answer.

Now swap the caller. The firm's procurement partner runs its own agent and sends the same request to Renly over A2A. The task goes to WORKING, then INPUT_REQUIRED while it waits for the same person's approval, then COMPLETED. Had she declined, the task would end REJECTED. Same governance, different door.

Where governance fits

Protocols move requests. They do not decide which requests are safe. That job belongs to whoever runs the agent, and there are two sides to get right.

  • When your agent uses someone else's MCP server, treat every tool as able to change things until you have reason to trust it. Ask for approval by default. Relax it only for read-only tools on servers you have decided to trust, and block tools you never want an agent to use.
  • When someone else's agent uses yours, over MCP or A2A, it should act with no more rights than the person who connected it, only on the agents they allowed, and it should never be able to approve its own actions. A paused task is not a failure. It is the system working.

Renly applies both rules. Tools from an MCP server you connect ask first by default, and admins can trust a server or set each tool to ask first, run without asking or block. When Renly is the server, outside tools and agents connect with an agent access key that acts as the person who made it, and approvals always happen in Renly. The developer guides for MCP and A2A show the details.

Try it in Renly

Both sides of MCP, and an Agent Card

Pick the part that matches your role. Part A needs an organization owner or admin; part B needs any Renly account and Claude Code (or another MCP client) on your machine.

A. Connect an MCP server to Renly (admins)

  1. Open organization settings and go to Connectors Settings, then the MCP Servers section. (If you do not see it, MCP servers are not switched on for your organization yet.)
  2. Choose Add Server. Give it a Name, choose the HTTP (Remote) transport, enter the Server URL from the server's documentation, choose its Authentication, and choose Add Server.
  3. Use the Discover tools action on the server. This is tools/list from earlier in the lesson: read the names and descriptions that come back.
  4. Open the server's Approvals section. Every tool starts at Ask first. Decide which, if any, should be Run without asking and which should be Block. Tick Trust this server's read-only labels only if you trust whoever runs the server.

B. Use Renly from another tool (anyone)

  1. From the user menu open Agent access. Under New key, name it (for example "Claude Code on my laptop"), leave only MCP ticked, pick one agent under Agents it can use, keep a short expiry, and choose Create key. Copy the key now: it is shown only once.
  2. In a terminal, run claude mcp add --transport http renly https://renly.ai/api/mcp-server --header "Authorization: Bearer rk_live_..." with your key in place of rk_live_.... (The Agent access page shows this command with your key filled in. To sign in instead of using a key, leave out --header and run /mcp in Claude Code.)
  3. In Claude Code, ask: "Use Renly to list my agents, then ask the agent for a summary of what it can do." Claude calls list_agents and ask_agent. Open the conversation link it returns: the same conversation is in Renly.
  4. For the A2A side, fetch Renly's public Agent Card: curl https://renly.ai/.well-known/agent-card.json. Find the endpoint, the skills, and the security scheme that asks for an access key.

When you are finished, revoke the key on the Agent access page. Anything using it stops working immediately. Full setup guides: MCP, A2A and agent access keys.

Key takeaways

  • MCP connects an agent to tools and data; A2A connects an agent to another agent.
  • In MCP, the host runs the conversation, a client connects to each server, and the server provides the tools and resources.
  • An A2A Agent Card advertises an agent's identity, skills, endpoint and authentication so others can find it.
  • A remote A2A agent waiting on a human decision reports INPUT_REQUIRED. ACP has merged into A2A.
  • Tool annotations are hints, not guarantees. Ask first by default, trust servers deliberately, and never let a caller approve its own action.