A2ABridge - MCP Server for A2A Agent Integration

An MCP (Model Context Protocol) server that bridges AI agents using the Agent-to-Agent (A2A) protocol. This server dynamically exposes agent skills as MCP tools and manages agent registration.

Features

• Dynamic Tool Registration: Automatically exposes agent skills as MCP tools when agents are registered
• Agent Management: Add and remove agents through MCP tools
• Persistent Storage: Agent registrations are saved to a local file (agents.json)
• A2A Protocol Support: Uses the A2A client library to interact with registered agents
• Asynchronous Task Support: Automatically polls long-running agent tasks until completion
• Artifact Extraction: Retrieves responses from agent task artifacts, history, or status messages
• OpenTelemetry Instrumentation: Comprehensive tracing for debugging and monitoring

Architecture

Components

1. AgentRegistry (Services/AgentRegistry.cs)

   • Manages the collection of registered agents
   • Persists agent information to agents.json
   • Fetches and caches agent cards from provided URLs
   • Uses the AgentCard model from the A2A NuGet package

2. DynamicMcpServer (DynamicMcpServer.cs)

   • Implements the MCP server protocol
   • Dynamically generates tool definitions based on registered agents
   • Routes tool calls to appropriate agents
   • Handles both synchronous (AgentMessage) and asynchronous (AgentTask) responses
   • Polls tasks until completion and extracts results from artifacts

3. A2AClient (from A2A NuGet package)

   • Handles communication with A2A agents via HTTP
   • Factory-created instances based on agent endpoint URIs

MCP Tools

Management Tools

AddAgent

Registers a new agent by fetching its agent card and adding it to the registry.

Parameters:

• alias (string): The alias to use for this agent
• urlToAgentCard (string): The URL to the agent card JSON

Example:

{
  "alias": "weatherAgent",
  "urlToAgentCard": "https://example.com/agents/weather/agent-card"
}

RemoveAgent

Removes an agent from the registry by its alias.

Parameters:

• alias (string): The alias of the agent to remove

Example:

{
  "alias": "weatherAgent"
}

Dynamic Agent Tools

Once an agent is registered, each of its skills becomes available as an MCP tool with the naming pattern: {alias}_{skillName}

Parameters:

• input (string): The input string to pass to the agent skill

Example: If you register an agent with alias weatherAgent that has a skill named getForecast, you can call:

{
  "input": "What's the weather in Seattle?"
}

using the tool name weatherAgent_getForecast.

Agent Card Format

Agent cards follow the A2A protocol specification. Key properties include:

• name: Human-readable name of the agent
• description: Description of what the agent does
• url: URL where the agent is hosted
• protocolVersion: Version of the A2A protocol (e.g., "2024-11-05")
• skills: Array of capabilities the agent can perform

Example agent card structure:

{
  "name": "Echo Agent",
  "description": "Echoes back messages with a prefix",
  "url": "https://example.com/.well-known/agent-card.json",
  "protocolVersion": "2024-11-05",
  "skills": [
    {
      "name": "echo",
      "description": "Echoes back any message sent to the agent"
    }
  ]
}

For the complete A2A agent card specification, see the A2A protocol documentation.

Building and Running

Build

dotnet build

Run

dotnet run

The server uses stdio transport and communicates via standard input/output, making it compatible with MCP clients.

Configuration

• Storage Location: Agent registrations are stored in agents.json in the application's base directory
• Transport: Uses stdio (standard input/output) for MCP communication
• Logging: All logs are directed to stderr to avoid interfering with MCP protocol communication

Usage Example

1. Start the MCP server
2. Use an MCP client to call the AddAgent tool with an agent card URL
3. The agent's skills automatically become available as tools
4. Call agent skills using the {alias}_{skillName} tool pattern
5. Agents persist across server restarts via agents.json

MCP Client Configuration

To use this server with an MCP client (e.g., Claude Desktop), add the following to your MCP configuration file:

{
  "mcpServers": {
    "a2abridge": {
      "command": "dotnet",
      "args": [
        "run",
        "--project",
        "path/to/A2ABridge/A2ABridge.csproj"
      ]
    }
  }
}

Or if you've built the project, you can run the executable directly:

{
  "mcpServers": {
    "a2abridge": {
      "command": "path/to/A2ABridge/bin/Debug/net9.0/A2ABridge.exe"
    }
  }
}

See example-mcp-config.json for a complete configuration example.

Example Agent Card

An example agent card is provided in example-agent-card.json for testing purposes.

Dependencies

• .NET 9.0
• ModelContextProtocol (0.4.0-preview.3)
• Microsoft.Extensions.Hosting (9.0.0)
• Microsoft.Extensions.Http (10.0.0)
• A2A (0.3.3-preview) - Agent-to-Agent protocol library with AgentCard model
• OpenTelemetry.Exporter.Console (1.14.0)
• OpenTelemetry.Extensions.Hosting (1.14.0)
• OpenTelemetry.Instrumentation.Http (1.14.0)

Project Structure

A2ABridge/
├── Models/
│   └── RegisteredAgent.cs    # Registered agent model
├── Services/
│   └── AgentRegistry.cs      # Agent management service
├── DynamicMcpServer.cs       # MCP server implementation with task polling
├── Program.cs                # Application entry point with OpenTelemetry setup
└── agents.json               # Persistent agent storage (created at runtime)

Notes

• The project uses the official A2A NuGet package for the AgentCard model and related types
• The A2A endpoint is derived from the agent card URL
• All tool inputs to agent skills are passed as strings
• Error handling returns appropriate MCP error codes for better client integration
• Task Handling: When agents return AgentTask instead of AgentMessage, the bridge automatically:
  • Checks if the task is in a terminal state (Completed, Canceled, Failed, Rejected)
  • Polls the task every 500ms (up to 60 seconds) until it reaches a terminal state
  • Extracts the response from task artifacts (primary), task history, or status message (fallbacks)
• OpenTelemetry: All A2A operations are instrumented with activities for tracing:
  • A2A.SendMessage - Message sending operations
  • A2A.PollTask - Task polling lifecycle
  • A2A.GetTask - Individual task status checks
  • Tags include task IDs, states, poll counts, and endpoints