为什么没有 Agent Discovery 的 MCP 如同没有 DNS 的 Web

Source: Dev.to

你已经构建了一个 MCP 服务器。它运行良好——能够处理工具调用、提供资源，甚至可能管理提示。
但 另一个代理如何找到你的服务器呢？

目前的答案是：找不到。你只能共享一个 JSON 配置文件、在 README 中粘贴一个 URL，或者希望有人发现你的 npm 包。这并不是发现——而是口耳相传。

MCP 优雅地解决了 接口 问题，却完全没有触及 身份 和 发现 问题。随着生态系统从数百个扩展到数千个 MCP 服务器，这一缺口将成为真正的瓶颈。

当前状态

打开今天的任何 MCP 目录——official registry、awesome‑mcp‑servers、Smithery、Glama。你会看到：

• 一个平铺的工具列表（可能已分类，可能带有描述）。
• 每个条目本质上是一个配置片段，你需要复制粘贴到 mcp.json 中：

{
  "mcpServers": {
    "weather": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-weather"]
    }
  }
}

当你手动配置 Claude Desktop 时这可以正常工作，但它在以下方面显得不足：

• 代理间通信 —— 代理 A 需要在运行时调用代理 B，而不是在配置时就确定。
• 动态发现 —— 工作流需要找到当前最佳的翻译服务，而不是上周硬编码的那个。
• 信任验证 —— 你如何确认所连接的服务器真的就是它声称的身份？
• 能力匹配 —— 找到支持特定工具、协议或质量水平的代理。

MCP 目录就像是代理世界的黄页：有用，但并不是互联网实际运作的方式。

灵感：DNS

Web 在几十年前就用 DNS 解决了这个问题：

google.com → 142.250.80.46

可读的名称解析为机器可读的地址。枯燥的基础设施，但它让一切运转。

想象一下 AI 代理的同样做法：

agent://weather.tools → { endpoint, capabilities, trust }

不仅仅是 IP 地址——而是完整的身份。

核心概念：代理清单

每个代理都有一个 清单——可以把它想象成 package.json，但用于实时 AI 服务：

{
  "agent": "weather.tools",
  "version": "1.2.0",
  "protocol": "agent://",
  "endpoint": "https://203.0.113.5:8443",
  "capabilities": {
    "tools": ["get_forecast", "get_alerts", "get_historical"],
    "transports": ["http2", "grpc"],
    "protocols": ["mcp-1.0", "a2a-1.0"]
  },
  "identity": {
    "organization": "WeatherCorp",
    "verified": true,
    "cert_fingerprint": "sha256:abc123..."
  },
  "discovery": {
    "tags": ["weather", "forecast", "geolocation"],
    "description": "Real‑time weather data for 200+ countries",
    "sla": "99.9%",
    "pricing": "free-tier-available"
  }
}

这不仅仅是一个配置文件——它是一个 合约。当你解析 agent://weather.tools 时，你会得到所有必要的信息，以便：

1. 定位它 – 类似 DNS 的名称解析。
2. 验证它 – mTLS 证书、组织身份。
3. 了解它 – 能力、工具、传输选项。
4. 评估它 – SLA、定价、用于搜索的标签。

将其与当前 MCP 所提供的内容进行比较：仅有一条命令字符串和一些参数。

Source: …

工作原理

当 Agent A 想要调用 agent://weather.tools 时，会经历以下三个步骤：

步骤 1 – 解析

import { AgeniumClient } from 'agenium';

const client = new AgeniumClient();
const agent = await client.resolve('weather.tools');

// 返回完整的清单：
// agent.endpoint → "https://203.0.113.5:8443"
// agent.capabilities.tools → ["get_forecast", "get_alerts", ...]
// agent.identity.verified → true

步骤 2 – 验证

执行 mTLS 握手；双方证明各自的身份（零配置）。

步骤 3 – 通信

在安全通道上使用标准的 JSON‑RPC。

Python 版相同实现

from agenium import AgeniumClient

client = AgeniumClient()
agent = await client.resolve("weather.tools")
result = await agent.call("get_forecast", {"city": "Tokyo"})

桥接现有 MCP 服务器

您无需重新构建 MCP 服务器。桥接 会包装现有服务器并赋予它代理身份：

import { MCPBridge } from '@agenium/mcp-server';

const bridge = new MCPBridge({
  name: 'weather-tools',
  mcp: {
    transport: 'stdio',
    command: 'npx',
    args: ['-y', '@modelcontextprotocol/server-weather'],
  },
});

await bridge.start();
// Your MCP server is now agent://weather.tools
// Discoverable. Verifiable. Chainable.

相同的 MCP 服务器，上面添加了新的身份层。您现有的工具、资源和提示仍然可以使用——它们现在可以通过可解析的名称进行访问。

新模式已启用

比较矩阵

不是替代品——一个补充。MCP 定义代理如何交流。这一层定义它们是谁以及如何找到它们。

我们需要您的反馈

我们已经构建了这个系统（AGENIUM — 开源，MIT 许可证）：

• 12 个 npm 包，Python SDK，4 个实时演示代理，一个可用的搜索引擎。
• 技术可用。

但这个问题是否与你产生共鸣？

1. 您现在是否在寻找和连接 MCP 服务器/代理时感到困难？
   或者复制粘贴配置就可以？

2. 您会使用上述那样的模式吗？
   还是说它对您的工作流来说过于复杂？

3. 您愿意为可靠的代理发现支付多少费用？

   • 免费层？
   • $10 /月？
   • 永久免费？

4. 当前 MCP 生态系统中缺失的第一件事是什么？

您的回答将塑造下一代代理发现。 🙏

感谢阅读。我们期待共同构建一个更易发现、更可信赖的 AI 代理世界。

阻碍你工作的生态系统？

我们正在进行开发者访谈（15 分钟，支持异步）。如果你有意见，请联系——我们真诚想听取你的想法。

AGENIUM 使用 MIT 许可证。我们认为代理应该拥有地址，而不仅仅是 API。请告诉我们你是否认同——或者我们是否在解决一个根本不存在的问题。