RFC: MCP Server Integration via A2A Protocol Bridge

[anivar]

Background

Currently, any-agent supports both MCP (Model Context Protocol) and A2A (Agent-to-Agent) protocols for serving agents. However, there's no way to bridge between these protocols. This creates silos where MCP tools can't be used by A2A agents and vice versa.

Proposal

Add a bridge capability to any-agent that allows MCP servers to be exposed as A2A-compatible services. This would enable:

1. Protocol Interoperability: MCP tools become accessible to A2A agents
2. Gradual Migration: Teams can transition between protocols without rewriting tools
3. Enterprise Integration: Connect local MCP tools with cloud-based A2A systems
4. Unified Tool Access: Use tools regardless of their underlying protocol

Implementation Approach

Core Components

1. MCP-to-A2A Bridge

   • Translates A2A requests to MCP tool calls
   • Handles protocol-specific differences
   • Manages connection lifecycle

2. Configuration

   • Simple config to specify which MCP server to bridge
   • Port and endpoint settings for the A2A interface
   • Identity configuration field (stored but not used)

3. Integration Points

   • Follows existing any-agent patterns
   • No custom rules or behaviors
   • Clean separation from native implementations

Example Usage

from any_agent.config import MCPStdio
from any_agent.serving import serve_mcp_as_a2a_async, MCPToA2ABridgeConfig

# Configure MCP server
mcp_config = MCPStdio(
    command="uvx",
    args=["mcp-server-time"],
    tools=["get_current_time"],
)

# Bridge to A2A
bridge_config = MCPToA2ABridgeConfig(
    mcp_config=mcp_config,
    port=8080,
    endpoint="/time-bridge",
)

bridge_handle = await serve_mcp_as_a2a_async(mcp_config, bridge_config)

Benefits

1. Immediate Value: Use existing MCP tools with A2A agents today
2. No Tool Rewrites: Bridge protocols without changing tool implementations
3. Flexibility: Run multiple bridges for different tools
4. Standards-Based: Works with standard MCP and A2A protocols

Considerations

• A2A's AgentCard doesn't support arbitrary metadata, so some MCP features may not translate
• Performance overhead of protocol translation (expected to be minimal)
• Each bridge handles one MCP server (by design, for simplicity)

Implementation Status

Implemented in PR #757

The implementation includes:

• Full protocol bridge with error handling
• Identity configuration field (stored internally, not used in A2A protocol)
• Comprehensive tests and documentation
• Cookbook example with practical usage patterns

[therealtimex]

Love the direction — turning MCP servers into A2A-discoverable “services” is exactly the kind of protocol bridge that will compound value across the AI stack. Below are specific suggestions to make the RFC more actionable and safer to ship.

Big-rock considerations

1. Ownership & boundary

• Keep the bridge in any-agent (as proposed) so mcpd remains a lifecycle/registry plane for MCP servers and identity issuance.
• Treat the bridge as a stateless sidecar: watch mcpd config/identity, generate A2A cards, proxy calls to MCP. No MCP runtime changes required.

2. Identity & auth (AGNTCY DID)

• Clarify how the bridge proves control of did:agntcy:mcpd:… identities issued by mcpd. Suggest a short-lived token minting flow:

  • mcpd signs a capability grant (audience = bridge, scopes = tool set).
  • bridge presents it to clients as “proof” via A2A auth metadata.

• Support per-tool scopes (least privilege) and audience binding (A2A client id). Default-deny unless explicitly allowed.

3. Permission model mapping

• MCP tends to be “call this tool” with optional auth inside the tool. A2A agents prefer declared capabilities + scopes.

• Add a translation table from MCP tool annotations → A2A scopes:

  • mcp.permissions: ["repo:read"] → a2a.scopes: ["github.repo.read"]
  • mcp.env_required: ["GITHUB_TOKEN"] → card auth.hints.required_secrets: ["github_token"]

4. Schema translation

• For each MCP tool:

  • name, description → action.title, action.description
  • JSON Schema (inputs) → action.parameters (preserve required, enums, formats)
  • Output: if tool publishes a schema, surface it in action.returns (optional but useful for validation).

• Decide granularity: one A2A “agent card” per MCP server (multiple actions) is generally better than one per tool.

5. Invocation semantics

• A2A call → bridge → MCP callTool.
• Timeouts: expose card-level timeouts and per-invocation overrides; map to MCP request timeouts.
• Streaming & cancellation: if MCP tool supports incremental output, expose A2A streaming (SSE/chunked). Support cancellation tokens end-to-end.

6. Discovery + hot-reload

• Watch mcpd.toml (or mcpd’s control socket/API if available). On change: regenerate cards, bump a discovery version and ETag.
• Provide stable IDs for cards derived from the DID + server slug to avoid client churn.

7. Errors & observability

• Normalize errors: MCPError{code,message,data} → A2AError{code,reason,details}; keep original data for debuggability.
• Emit OpenTelemetry spans on both sides (bridge and MCP call), including tool name, latency, status, token counts (if available).

8. Limits & policy

• Add server-level quotas: rate limit per tool and per DID audience.
• Redact secrets in traces by default. Expose an opt-in debug mode gated by policy.

Straw-man API

Bridge creation

from any_agent import MCPToA2ABridge

bridge = MCPToA2ABridge(
    mcpd_config_path="~/.config/mcpd/mcpd.toml",
    identity_resolver="mcpd",  # or custom resolver plug-in
    exposure={
        "host": "0.0.0.0",
        "port": 8080,
        "streaming": True
    },
    policy={
        "default_opt_in": False,          # opt-in per server/tool
        "rate_limits": {"burst": 10, "rps": 5},
        "max_timeout_ms": 120_000
    }
)
await bridge.serve()

Generated (example) A2A card (abridged)

{
  "id": "did:agntcy:mcpd:MyOrg:github-server",
  "title": "GitHub MCP",
  "description": "GitHub operations exposed via MCP",
  "auth": {
    "type": "agntcy",
    "scopes": ["github.repo.read","github.repo.write"],
    "hints": { "required_secrets": ["github_token"] }
  },
  "actions": [
    {
      "name": "issue.create",
      "description": "Create an issue",
      "parameters": { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "properties": { "repo": {"type":"string"}, "title": {"type":"string"}, "body": {"type":"string"} }, "required": ["repo","title"] },
      "returns": { "type": "object", "properties": {"url": {"type": "string"}} },
      "timeout_ms": 30000
    }
  ],
  "version": "1.0.0"
}

Call flow (pseudo)

A2A client → POST /agents/{card_id}/actions/{name}: {args}
Bridge → MCP callTool(name,args,auth)
MCP → result stream / final result
Bridge → stream/final JSON to client

[anivar]

Implementation complete in PR #757

Thank you for the detailed feedback @therealtimex. The implementation takes a pragmatic approach that aligns with any-agent's philosophy while addressing several of your suggestions:

What's implemented:

• Stateless bridge that translates between MCP and A2A protocols
• Single MCP server per bridge instance (as you suggested for granularity)
• Identity support via AGNTCY DIDs from mcpd (logging only due to A2A constraints)
• Clean error handling and protocol translation
• No modifications to MCP runtime

Key design decisions based on implementation experience:

1. Simplicity first - Single-tool bridges avoid complex permission mapping
2. Identity tracking - DIDs are logged but not exposed (A2A AgentCard lacks metadata field)
3. No custom auth - Relies on existing MCP/A2A mechanisms
4. Minimal configuration - Just specify MCP server and A2A endpoint

What we learned:

• A2A's AgentCard structure is more limited than expected (no arbitrary metadata)
• Simple bridges are more maintainable than complex multi-tool orchestrators
• Protocol translation works well for basic tool invocation

Next steps could include:

• Schema translation as you suggested
• Streaming support when both protocols align
• Hot-reload from mcpd config changes
• OpenTelemetry instrumentation

The current implementation provides immediate value while leaving room for these enhancements. It validates the bridge approach and demonstrates practical interoperability between MCP and A2A.

[anivar]

Working demo available: https://github.com/anivar/mozilla-ai-protocol-bridge

Shows both MCP-to-A2A (PR #757) and MCP-to-ACP (PR #774) bridges with identity integration.