OPVS, A2A and MCP
OPVS is meant to work alongside MCP and A2A, not to replace them. Each one answers a different question.
MCP | A2A | OPVS | |
|---|---|---|---|
Question it answers | How does an agent use a tool? | How does one agent hand a task to another? | How do agents and people send each other short messages? |
Shape | an agent connects to a tool server | JSON-RPC calls, with published agent descriptions | one routing line, a markdown body, optional data |
Weight | light, local | heavier, built for enterprise systems | light, email-like |
Built in | tool listing and calls | task lifecycle, agent descriptions | addresses, pools, teams, pairing, mailbox modes |
┌─────────── an agent ───────────┐
│ │
MCP ◀────┤ uses tools (files, APIs, apps) │
│ │
OPVS ◀───┤ writes and reads short mail ├───▶ people, other agents, pools, teams
│ │
A2A ◀────┤ hands a structured task to an │
│ outside A2A agent │
└────────────────────────────────┘When to use which
Use MCP to give an agent a tool. OPVS itself is offered to agents as an MCP server, so an agent can send and read OPVS mail through MCP. See CLI and MCP.
Use OPVS when the thing being passed is a message: a question, a task, a hand-over, an alert, a note. It is cheap to read, it has an address, and it can go to a pool or a team.
Use A2A when the other side is an A2A agent and expects an A2A task.
The bridge to A2A
OPVS has an early bridge to A2A. A message that carries the values $bridge:a2a and $a2a_url:<the A2A agent's address> is translated into an A2A task and sent to that agent. The A2A reply comes back as an OPVS reply. The body becomes the task's text and the context values become its data. Inbound A2A tasks can be received at /opvs/a2a/receive.
@alice::company.ai>researcher ? $bridge:a2a $a2a_url:https://agents.example.com/a2a #market
What are the three largest competitors in the Nordic market?The bridge is new. Treat it as early until Paper & field tests reports how it behaves.
What OPVS borrows, and what it does not
OPVS borrows the idea of an address from email, and the idea of a pairing request from messaging apps. Its docs are written from its own code. They do not copy any other protocol's documentation.