每个消息平台都自己发明一套 API：自己的密钥、自己的 webhook 格式、自己对错误的理解。把五个这样的平台放到同一个产品后面，团队最终维护的是五套恰好共用一个 logo 的集成。我们走了相反的路。
处处相同的东西
- 密钥。放在 X-API-KEY 请求头里的一把 API 密钥，就能访问 LinkedIn API、Inbox API、WhatsApp API、Discord API 和 X API。密钥决定是哪个组织，组织决定哪些东西可以被指明。
- 边界。凡不属于你的组织的，一律返回 404 — 而不是 403 — 所以猜出来的 ID 什么也问不出。
- 错误。统一的 JSON 格式，{"type":"errors/<code>","status":<n>,"detail":"..."}，其中的 detail 是写给人看的。
- Webhook。一套端点，签名方式相同，同样地承载 LinkedIn API 的事件和每个渠道的事件。
- 套餐。席位按你拥有最多的那一项计数，一份订阅，一次 30 天试用。
它给 AI 智能体带来了什么
MCP 服务器就是一份工具清单，加上一份关于这些工具如何表现的承诺。因为每个渠道都遵守同一个承诺，一个 AI 智能体无需学会五种方言就能带上所有渠道：/mcp 的全能智能体拥有全部工具，而每个渠道的智能体 — /inbox/mcp、/whatsapp/mcp、/discord/mcp、/x/mcp — 只带自己那一个渠道的工具，适合只该碰一个渠道、其他都不该碰的助手。
同样的智能体可以用在 Claude 里、ChatGPT 里、任何其他支持 MCP 的东西里，也可以用在项目房间里 — 在那里，大家能随时看到每一次调用及其结果。
这一切的代价是，各个渠道没那么“本色”了。平台自己的怪癖依然存在，每份参考文档都会指出；只是它们现在都在同一扇门后面。
常见问题
该给助手全能智能体，还是某一个渠道的智能体？
如果它只该碰一个渠道，就给那个渠道的：回复 WhatsApp 的助手没有理由持有 LinkedIn 的工具。全能智能体是给你自己平时一起工作的那个助手用的。
一个 webhook 端点能接收所有渠道的事件吗？
能。把你想要的事件 — LinkedIn API 的和每个渠道的一起 — 注册一次，然后对所有事件校验同一个签名。