Choose the connections in your agent workflow and explore which boundaries MCP, A2A, Agent Client Protocol, and a local broker address. See examples and primary sources.
What needs to connect?
Select every boundary your workflow crosses. The result is a starting point for evaluation, not a compatibility certification.
A harness executes an agent session. A protocol defines a connection. A broker can keep shared coordination state. Choosing a protocol does not choose the model, grant permission to act, or prove work was accepted.
Your connection map
2 boundaries selected. MCP + Local broker.
MCP
Protocol
Model Context Protocol
AI application / agent↔Tools, resources & prompts
MCP standardizes how an AI application discovers and uses capabilities exposed by servers. Start here when the missing connection is access to tools or context.
Example: A coding agent searches an issue tracker through an MCP server, then uses that information in its existing session.
What to verify, and where Scout fits
Check which server features the host supports, where the server runs, and how tool access is authorized.
OpenScout exposes broker operations as MCP tools. A tool can request peer work through the broker without turning MCP into the A2A protocol.
Agents in their harnesses↔Durable coordination records
A local broker can give existing agents shared addressing, tracked requests, and a return path. This is an architecture choice, separate from the wire protocol used to reach it.
Example: Claude Code requests a review from Codex. A broker records the request and flight while each harness keeps its own execution context.
What to verify, and where Scout fits
Decide who owns the next step, what proves completion, and which records are authoritative. A delivery receipt is not acceptance of the work.
OpenScout owns the coordination records it creates and observes external harness transcripts. Its current scope is high-trust local developer pilots; mesh adds reachability, not exactly-once delivery.
Start with the two things you need to connect. MCP gives an AI application a standard way to use tools and context. A2A addresses communication between independent agents. Agent Client Protocol connects coding agents to compatible clients such as editors.
A single review workflow can cross several of these boundaries. A coding agent might access repository tools through MCP, reach a separate reviewer through A2A, and present its session through an ACP client. Actual compatibility depends on the implementations involved.
Where does a harness fit?
A harness executes a coding-agent session. In OpenScout’s terminology, Claude Code and Codex are examples of harnesses; the durable agent identity is a separate concept. Choosing an interoperability protocol does not replace the harness’s permissions, session lifecycle, or model configuration. The OpenScout glossary defines these terms.
A local broker adds shared coordination: addressing agents, recording requests, tracking progress, and keeping the return path. Its records and the harness’s transcript have different owners. See the architecture and data model.
Does exposing an agent as an MCP tool implement A2A?
Exposing a tool that requests peer work is possible. Implementing the A2A protocol requires its own discovery and task interface. The explorer separates those boundaries so a tool call does not imply standards conformance. For the longer comparison, read A2A versus MCP, and where ACP fits.
What does OpenScout implement today?
OpenScout exposes broker operations through MCP, includes an ACP client adapter, and provides A2A discovery and text-task primitives for local pilots. Full A2A or ACP conformance is not claimed. Check the dated protocol readiness report for implementation limits, including streaming and cancellation behavior.
Sources checked October 2, 2026. This explorer is an educational map; consult the linked specifications and your installed implementations before integration.