译自 Dries Buytaert 博客原文：Helping agents discover my site search with MCP（2026 年 8 月 4 日）。

这是"让站点的搜索能力对 AI 智能体可用"系列的第三篇。第一篇，我发布了一份 API Catalog，帮那些已经知道要去检查我站点的智能体找到它的搜索 API。第二篇，我加了一条 Agentic Resource Discovery（ARD）记录，让我的搜索能被"AI 注册表"收录（可以理解成面向 AI 智能体的搜索引擎）。

到现在为止，还没有任何智能体自己找到我的搜索。API Catalog 成为已发布的 IETF 标准已经一年多了，但我没找到任何证据表明 OpenAI 或 Anthropic 会去检查它。ARD 更新一些，还是 v0.9 草案，我也没找到证据说 OpenAI 或 Anthropic 支持它。

与此同时，真正管用的是我写的一个自定义 Agent Skill，它把我的 AI 助手指向 API Catalog，再从那里指向我的 OpenAPI 描述，最后指向搜索本身。如果有朝一日智能体采纳了其中某一个或几个发现标准，我也许就能把这个 skill 删掉，让它全自动地跑起来。

直到上周，我还认为 Model Context Protocol（MCP）不值得为我的搜索端点实现。它需要一次初始化握手，还可能涉及协议层的会话。而我的搜索两样都不需要：每个查询都是无状态、匿名的。对这么简单的用例来说，MCP 显得太重了。

2026-07-28 这一版修订改变了我看法，因为协议层会话和初始化握手都没了。现在每个请求都可以是自包含的，这意味着，对像我这样的服务来说，一个 MCP 服务器基本上就是一条返回 JSON 的 POST 路由。

于是我着手为搜索端点实现了 MCP 支持。整个东西加起来是一条路由加三个小 RPC 方法：不算测试的话，不到 150 行代码。

你可以从任何终端调用它

在我的测试里，把我的站点作为自定义 MCP 连接器加到 Claude Desktop、Claude Code 或 ChatGPT 里仍然失败。这些客户端还不支持新协议——这可以理解，毕竟它才一周大。等它们跟上，任何人都能把 dri.es 加为连接器，而不只是我自己。

在那之前，用 MCP 客户端和我站点对话的一个简便办法是 Simon Willison 的 mcp-explorer。你可以用 uvx（随 uv 一起安装）来跑：

uvx mcp-explorer list https://dri.es/mcp
uvx mcp-explorer call https://dri.es/mcp find_posts -a query "open source"

第一条命令会打印每个工具的名称、描述和参数。第二条会在我的文章里做一次搜索，返回最多二十条结果。

另一种方式是直接用手工的协议调用，在终端里跑这条 curl：

curl -s https://dri.es/mcp \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/call" \
  -H "Mcp-Name: find_posts" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"find_posts","arguments":{"query":"open source"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}' \
  | jq .result.structuredContent

发现和调用是两个不同的层

在实现了对三个新标准的支持之后，我学到的一件有用的事是：它们并不是互相替代的关系。

ARD 负责发现：它给注册表一种标准方式去收录和搜索像我这样的服务。OpenAPI 和 MCP 负责调用：它们定义了智能体如何调用和使用这些服务。

所以选择不是"ARD 还是 MCP"，而是"ARD 加 OpenAPI"，或者"ARD 加 MCP"。

对于像我这样一个匿名、只读的 API，我更喜欢 OpenAPI。它实现起来更容易，任何能发 HTTP 请求的东西都能用。

当你的服务涉及多步交互、身份认证或者明确的应用程序状态时，MCP 才变得更有吸引力。

最终，决定权在智能体和爬虫的采用情况上。时间会给出答案，但眼下我押注 ARD 和 MCP。