Solace Agent Mesh MCP and A2A: How Agents Reach Tools and Each Other

Solace Agent Mesh MCP support works in two directions, and A2A is how its agents talk to each other. Agents call tools on external Model Context Protocol (MCP) servers, and an MCP entrypoint lets outside MCP clients call the mesh’s agents as tools. Between agents, Agent Mesh uses an Agent-to-Agent (A2A) protocol carried as JSON-RPC 2.0 messages on Solace event broker topics, with a proxy for external agents that speak A2A over HTTPS. This page explains both protocols, where their governance now sits, how Agent Mesh uses each as of October 2026, and what to watch.

It belongs to the Solace Agent Mesh overview in the Solace cluster.

MCP and A2A in brief

MCP connects an AI application to tools and data. Anthropic introduced it in November 2024 as an open protocol so that any model client could use any tool server without custom integration. On 9 December 2025 it was donated to the Linux Foundation’s new Agentic AI Foundation, co-founded with Block and OpenAI. The specification is at modelcontextprotocol.io.

A2A connects agents to agents. Google announced Agent2Agent in April 2025, and the Linux Foundation launched it as a project on 23 June 2025 with AWS, Cisco, Microsoft, Salesforce, SAP and ServiceNow among the backers. Agents describe themselves with an agent card, and hand each other tasks that move through defined states.

	MCP	A2A
Connects	An AI application to tools, data and prompts	One agent to another agent
Typical exchange	Call a tool, get a result	Hand over a task, follow its status, get an outcome
Discovery	The client lists a server’s tools	Agents publish an agent card describing skills
Governance as of October 2026	Linux Foundation, Agentic AI Foundation	Linux Foundation, Agent2Agent project
Role in Agent Mesh	The edges: tools agents use, and clients that use agents	The inside: every message between workloads and agents

Why both matter to a buyer: they are the two places where lock-in usually hides. A platform that speaks both lets you replace a tool, a model or an agent framework without rewriting the rest. Solace makes exactly that claim, that open protocols let users swap models and tools (product page), and the docs below support it with some caveats.

Solace Agent Mesh MCP and A2A in the stack

Solace Agent Mesh MCP: agents as clients and as servers

Agents as MCP clients. An agent’s tool list can include MCP servers. The tools documentation supports three transports: stdio (“spawn the MCP server as a subprocess and speak over its stdin/stdout”), SSE and streamable HTTP. Authentication can be bearer, basic, headers, OAuth 2.0 or none, and allow_list, deny_list and tool_name_prefix limit which of a server’s tools the agent sees. Solace’s own security advice is to use allow_list “to limit exposure to malicious tool descriptions” and a CA bundle rather than disabled TLS verification.

Agents as MCP servers. The MCP entrypoint turns the mesh inside out: MCP clients such as Claude Code, MCP Inspector or an IDE plugin connect over Streamable HTTP, discover the deployed agents, and call them as tools. By default every agent appears; include and exclude patterns such as public-* narrow that. With OAuth on, each call runs as the authenticated caller with that user’s RBAC scopes. With OAuth off, a run_as system user supplies the scopes, which is convenient and easy to over-grant.

An illustrative plant example. A reliability engineer working in an AI-enabled IDE asks for last week’s top downtime causes on Line 3. The IDE calls a “downtime-analyst” agent through the MCP entrypoint; that agent calls a historian query tool and an MCP server in front of the CMMS, then returns a summary. The engineer never sees the broker, and every call carries the engineer’s own identity. Getting plant data into a shape agents can query is the same work as building a unified namespace, and it is usually the larger job.

A2A over the event mesh

Inside the mesh, A2A rides on topics. Solace’s A2A protocol page describes “a JSON-RPC 2.0 dialect carried over event broker topics, and a frozen wire contract”. Requests go to <namespace>/a2a/v1/agent/request/<agentName>, agent cards to <namespace>/a2a/v1/discovery/agentcards, and tasks move through submitted, working and completed, failed or canceled, with input-required and auth-required pauses. One detail catches integrators: field names are snake_case on the broker and camelCase over HTTP.

Outside agents join through a proxy. The external agents page describes a proxy that fetches an agent’s card from /.well-known/agent-card.json, a custom URL or a manual entry, then forwards tasks from the broker to the agent’s HTTPS endpoint and streams answers back. Credentials can be none, a static bearer token, an API key or OAuth 2.0 client credentials. An agent with no card shows as “Registered” rather than “Running”, because the platform cannot check its health.

Why carry A2A on a broker? The public A2A specification is built around HTTP between agents. Putting it on topics adds what a broker always adds: the sender does not need the receiver’s address, delegation works across pods and sites, and many subscribers can watch the same task stream. There is a cost, too. A broker-carried dialect is only as portable as its bridge: an agent built for Agent Mesh speaks A2A to the outside world through the proxy, not natively, and a future move to another platform means re-testing that boundary. In our view the trade is reasonable for an organisation that already runs Solace as its integration backbone, and harder to justify for a team adopting a broker only to host agents. The event mesh page explains how Solace routes those topics between brokers.

Other Solace MCP servers

Agent Mesh is not Solace’s only MCP work. solace-broker-mcp, an open-source Go server created in March 2026, exposes 47 SEMP-based broker tools, 29 read-only and 18 write or action tools that are off by default. Event Portal has an MCP server that lets AI coding assistants read the event catalogue; see Solace Event Portal. On the competing side, Confluent’s Real-Time Context Engine serves streaming context over MCP, and Redpanda’s Agentic Data Plane announced MCP and A2A support in October 2025; the Agent Mesh overview compares them.

Where it gets hard

• MCP servers are code you did not write. Tool descriptions are read by the model and can carry instructions. Allow-list tools, pin server versions and review every new server like a new integration.
• Identity must flow end to end. Run MCP calls as the real user wherever possible. A shared run_as account quietly widens access.
• Specification drift. Both MCP and A2A are moving under new foundations. Solace’s docs do not state which A2A specification version the broker dialect tracks; ask before you rely on interoperability.
• Request and response is not events. MCP is a call-and-answer protocol. It does not push changes to an agent; the broker does. Design which agents subscribe to events and which wait to be asked.
• Plant reach. Any MCP server in front of an OT system is a new path into that zone. Place it deliberately, following OT network segmentation in brownfield plants.

---

Related: Solace Agent Mesh overview · Solace Agent Mesh architecture · Editions and licensing · Solace hub