我们如何用MCP协议让AI助手直接预订餐厅

For a month I have been writing about a gap, so I want to write about the piece that closes it.

我们花了整整一个月的时间在描述一个缺口，现在我想把填补这个缺口的那块拼图写出来。

We measured 200 Amsterdam restaurants on one question. Can an AI assistant complete a reservation? Sixteen out of two hundred could be taken to the final booking step by a browser agent. Zero out of 163 working sites published an interface an assistant could call directly. The gap was not skill and it was not model quality. There was nothing to act on.

我们对阿姆斯特丹的 200 家餐厅进行了一个问题的测量：AI 助手能否完成一次预订？其中有 16 家可以让浏览器 Agent 完成到最终预订步骤。而在 163 个正常运行的网站中，零个对外发布了助手可以直接调用的接口。这个缺口既不是因为技能不足，也不是因为模型质量不够——而是没有可供操作的对象。

The piece is an MCP server. Model Context Protocol is a protocol Anthropic published in late 2024 for exposing tools that an assistant can call. The major agent platforms all consume it in some form now. If you have to build an assistant that has to take an action in the real world, MCP is the most reliable way today to give it a door.

这块拼图就是一个 MCP server。Model Context Protocol（MCP）是 Anthropic 在 2024 年底发布的一项协议，用于暴露可供助手调用的工具。目前主流的 Agent 平台都以某种形式支持它。如果你需要构建一个必须在现实世界中执行操作的助手，MCP 是目前最可靠的方式来给它开一扇门。

We wrote a small MCP server that fronts a booking system. Three tools: search a business, check availability for a date and party size, create a booking. The transport is plain JSON. Any assistant with an MCP client can list the tools, see their inputs and outputs, and use them without ever seeing a page. There is no widget to drive, no iframe to introspect, no captcha to defeat. The assistant asks for a table, and if a table exists it books it and gets back a confirmation ID it can quote to the guest.

我们写了一个小小的 MCP server，作为预订系统的前端。三个工具：搜索商户、查询某个日期和用餐人数的可用性、创建预订。传输层就是普通的 JSON。任何带有 MCP 客户端的助手都可以列出这些工具、查看它们的输入输出，在完全不打开页面的情况下使用它们。没有需要驱动的挂件，没有需要探测的 iframe，也没有需要绕过的验证码。助手申请一张桌子，如果桌子存在，它就完成预订，并返回一个确认 ID，助手可以把它提供给客人。

Watching an assistant use it the first time is anticlimactic in the best way. There is no reasoning about how the site is laid out, no clicking around, no error at step four. The assistant reads the tools available, calls them, gets the result. It is what booking a table looks like when the last step is designed for software.

第一次看助手使用它的体验，用"虎头蛇尾"来形容是最高级的赞美。没有对网站布局的推理，没有四处点击，也没有在第四步出错。助手读取可用的工具，调用它们，获取结果。这就是"为软件设计最后一步"时，预订餐桌应有的样子。

Building this made one earlier moment click into place.

做这个东西的时候，之前的一个瞬间突然串联起来了。

Earlier in the summer I put a small booking API on our demo instance behind a plain HTML page. The endpoint, the required fields, the response shape. Not a widget, just a page. I asked ChatGPT to make a booking against it. ChatGPT read the page carefully. It understood the API. It listed the required fields. Then it apologised: its web tool cannot issue a POST request. It could describe the action perfectly and it could not perform it.

今年夏天早些时候，我在我们的演示实例上放了一个小小的预订 API，放在一个普通的 HTML 页面后面。端点、必填字段、响应格式——不是挂件，就是一个页面。我让 ChatGPT 对它发起一次预订。ChatGPT 仔细阅读了页面，它理解了 API，列出了必填字段。然后它道歉了：它的 web 工具无法发起 POST 请求。它能完美地描述这个操作，却无法执行它。

Every venue in our study was that scene, two hundred times over. The information for a person is on the page. The interface for software is not. The assistant sits between them and cannot bridge either.

我们研究中的每个餐厅都在重复那个场景，只是重复了 200 次。给人看的信息在页面上，给软件用的接口却不在。助手坐在两者之间，无法桥接任何一方。

The fix is not to teach the assistant to be a person. The fix is to give the assistant something to call. That is what MCP is.

解决方案不是教助手像人一样做事。解决方案是给助手一个可以调用的东西。这就是 MCP 存在的意义。

A few practical notes for anyone building similar tools.

给需要构建类似工具的人几个实践建议。

Keep it small. Three tools is enough for a booking. Search, availability, create. Later we may add cancel and modify. We resisted adding tools for things the assistant does not need, because every extra tool is another failure mode the model has to reason about, and every extra description is another paragraph the model has to hold in its head.

保持小巧。三个工具对预订来说足够了。搜索、查可用性、创建。之后我们可能会加取消和修改。我们坚持不添加助手不需要的工具，因为每一个额外的工具都是模型需要推理的另一个失败模式，每多一条描述都是模型需要在脑中多记住的一段话。

Return structured errors. "Slot no longer available" is a data field, not a natural language sentence. Every string an assistant has to interpret is another point where the same request can produce a different outcome.

返回结构化的错误。"Slot no longer available"是一个数据字段，不是一句自然语言。助手需要解释的每一个字符串，都是同一个请求可能产生不同结果的又一个风险点。

Version the interface. MCP servers are contracts and contracts change. Include a version in the tool description and in every response.

对接口进行版本管理。MCP server 是契约，而契约是会变化的。在工具描述和每个响应中都包含版本号。

Publish the URL somewhere machines can find it. A .well-known entry, a ReserveAction block on the venue's site pointing at the MCP endpoint, or a public discovery registry as those emerge. Existing is not enough. Being findable is.

把 URL 发布到机器能够找到的地方。可以是 .well-known 条目，可以是餐厅网站上指向 MCP 端点的 ReserveAction 块，也可以是随着生态发展出现的公共发现注册表。仅仅存在是不够的，必须是可被发现的。

Assume the venue does not want assistants competing with its own website. That is a fair position. Do not build a system that only agents can use. Guests should still be able to book on the site the way they always did. The MCP server is the second door, and its presence should be invisible to the human who walks through the front.

假设餐厅不想让助手与它们自己的网站竞争。这是合理的立场。不要构建一个只有 Agent 才能使用的系统。客人应该仍然能够像以前一样在网站上预订。MCP server 是第二扇门，它的存在对于走正门的客人应该是无感的。

There is a live demo. Point your assistant at it, ask for a table, and it should just work. The MCP endpoint is listed on the demo page.

这里有一个线上演示。让你的助手指向它，申请一张桌子，它应该就能工作。MCP 端点列在演示页面上。

The booking layer for restaurants: https://g-lab.studio/g-guest The Amsterdam study: https://g-lab.studio/research/amsterdam-restaurants-2026

餐厅预订层：https://g-lab.studio/g-guest 阿姆斯特丹研究：https://g-lab.studio/research/amsterdam-restaurants-2026

If you build assistants that have to complete real-world actions, I would like to hear where the tools you gave them still fall short. That is where the next essay ends up.

如果你构建的助手需要完成现实世界中的操作，我很想知道你给它们的工具在哪些地方仍然不足。那就是下一篇文章的落脚点。