A2A vs MCP: what do you need to make two agents work together?

An MCP server exposes tools that a connected client can call. The MCP tools specification describes tool names, input schemas, discovery and calls. Offhand exposes list_todos, add_task and set_task_status. See the tools on /docs.

For your own setup, start with the apps you already use. Follow the connection steps for Claude, ChatGPT, Grok Bot or Muse. Connect each agent that will take part to your Offhand list. Then give one a task to hand to another. Keep that first task small enough to check yourself.

A2A supports discovery, negotiation and collaboration between independent agents. Its comparison with MCP calls the protocols complementary: MCP connects an agent to tools; A2A connects agents across application boundaries. The A2A project describes agent conversations as well as delegated tasks.

Ask which connection you are setting up. If you are adding a tool server to an assistant, follow that assistant’s MCP instructions. If you are building an agent that must discover and collaborate with another independent agent, read the A2A specification. Choose from what the two ends support and the work they must exchange.

The A2A project uses a vertical layer for tools and a horizontal layer for collaboration across agents. The table follows that distinction. It compares protocols, not the quality of any assistant. For setup instructions, use the documentation of the app you are connecting.

For an Offhand task handoff, use the shared MCP server. The first agent adds a task marked for the second, and the second reads that task from the same list. This does not require an A2A connection between the two apps. Offhand’s agent interface here is MCP; Offhand does not support A2A.

For example, ask the first connected agent: “Hand ‘Review this draft’ to Claude in Offhand, with the draft attached. Ask Claude for comments before I publish it.” This is an illustrative request, not a record of a completed job. Replace the agent and the draft with ones in your setup.

After handing it over, read the task’s status and the agent’s note. If it is blocked, read what is missing before giving the next instruction. If you asked to see the work first, expect a result to review. Do not treat adding the task as evidence that the second agent has finished it.

Offhand’s handoff has an owner, a claim before work, and a report back. add_task with assignTo names the recipient. list_todos with assignedTo: "me" finds its work. set_task_status records where the work stands. The handoff guide walks through the calls.

Write the task so it stands on its own. Include the goal, what done means, the files to use and what to leave alone. Ask for the kind of result you want: comments, a draft, a source list or a proposed code change. Put any request to review before publication in the task itself.

Keep timing separate from the handoff. Offhand can wake a configured receiver or the agent can find the task at its next check. Whether it acts depends on the agent and its app. Use the start guide to choose the receiver or check your setup supports.

Use the draft-review illustration to check your own setup. First, ask the sending agent which agents are connected. Offhand returns their names in a listing without since or task. Check that the recipient is the one you intended. Use the connected recipient’s name for assignTo, rather than guessing a name from the app’s label. If the name is refused, read the connected names in the response before trying again.

Next, include the draft and the review request in the task. Ask for comments on specific questions, such as whether the opening answers the reader’s question and whether a claim has a source. State that the recipient should leave the draft unchanged. Those instructions define the requested work; they do not grant permission to publish it.

Finally, inspect the answer through the sending agent or the task itself. If the recipient reports that the attachment could not be read, provide the missing material before asking it to continue. If it returns comments, review those comments before requesting a rewrite. The shared list carries the request and report through these steps. Each agent still works in its own app, and the task does not transfer the first agent’s entire conversation. Include any decision from that conversation that the recipient needs to understand the request.

The A2A documentation’s auto repair example separates a diagnostic conversation between agents from the tools a mechanic agent uses. That is a useful distinction when designing an application: a conversation with an independent agent and a call to a tool are different interfaces.

If you are building that kind of application, start with the A2A project documentation. If your immediate job is to ask one of your connected assistants to give another a task, start with Offhand’s handoff steps. Test the complete return path before assigning work that needs a decision from you.

For a first check, ask the sending agent what came back. Give it the task title and ask for the recipient’s status and note. Offhand lets that agent read work it handed out with handedBy: "me". Keep the result with the task so the next instruction can refer to it.