A2a MCP Proxy

a2a mcp代理

使用Agent2Agent协议，以高昂的代价，对大多数MCP客户端忽略的MCP规范部分进行聚合填充

问题

这 模型上下文协议（MCP） 这是一个强大的标准，但客户合规性……参差不齐。

最明显的遗漏是什么？ 动态更新。

MCP规范包括 notifications/tools/list_changed 和 notifications/resources/list_changed这些对于一个有生命、有呼吸的主体生态系统至关重要，在这个生态系统中，工具和资源会根据上下文出现和消失。

大多数客户忽略了这些。他们在启动时获取一次列表，从不回头。这会破坏任何试图提供上下文感知工具的服务器。

解决方案

a2a mcp代理 是这个问题的强力解决方案。

它充当MCP客户端和MCP服务器之间的中间件代理。它聚合了客户端忽略的协议的动态特性。

1.“昂贵”的Polyfill

当服务器通知工具或资源已更改，但客户端对通知置若罔闻时，代理会介入。它管理客户端所处的世界状态 *应该* 看。

2.能力系统（增强MCP）

我们不只是修补漏洞；我们升级了人行道。

a2a mcp代理 介绍a 能力体系这确保了客户端代理只能访问适合其自身的工具和资源 *当前形势*.

• 按工具和按资源访问控制：访问不是二进制的。这是情境。
• 上下文感知可见性：如果代理现在不应该看到工具（例如，在“研究”阶段时的“部署到生产”），则此代理会隐藏它。
• 动态执行：随着代理的上下文发生变化，其功能也会发生变化。即使客户端试图使用过时的工具定义，代理也会实时执行此操作。

建筑

sequenceDiagram
    participant Client as Static MCP Client
    participant Proxy as a2a-mcp-proxy
    participant CapSys as Capabilities System
    participant Server as Dynamic MCP Server

    Client->>Proxy: Connect
    Proxy->>Server: Connect

    Note over Server: Tools List Changes!
    Server->>Proxy: notifications/tools/list_changed
    Proxy--xClient: Client ignores notification...
    
    Note over Proxy: Proxy updates internal state
    
    Client->>Proxy: Call Tool "Deploy"
    Proxy->>CapSys: Can agent use "Deploy" right now?
    CapSys-->>Proxy: NO (Context: Research Phase)
    Proxy-->>Client: Error: Tool not available in current context
    
    Note over Client, Server: Later...
    
    Client->>Proxy: Call Tool "Search"
    Proxy->>CapSys: Can agent use "Search" right now?
    CapSys-->>Proxy: YES
    Proxy->>Server: Call Tool "Search"
    Server-->>Client: Result

“花费巨大”

为什么这么好笑？因为这是真的。

我们实际上是在使用一个复杂的、可能包含大量令牌的LLM代理循环（通过Agent2Agent）来模拟基本协议功能并强制执行以下逻辑 *应该* 可以是客户端本地的，也可以由简单的状态机处理。

• 延迟：高。
• 成本：非零。
• 复杂性：荒谬。
• 合规: 100%.

用法

*（实施完成后添加说明）*

许可证

麻省理工学院