2 天内构建 20 个 MCP App 的经验教训
我的团队在两天内构建了 20 个 MCP App。这让我对这些工具的功能以及它们的局限性有了清晰的认识。
MCP App 是 MCP 规范的第一个官方扩展。它们允许工具在返回结果的同时返回一个 UI 资源。宿主（host）会在一个沙箱化的 iframe 中渲染该 UI。你可以直接在聊天界面中展示表格、图表和表单。
视觉信息通常比文本更有效。图表比 CSV 文件更直观。拉取请求（pull request）列表比一大堆文本更容易阅读。
以下是我们学到的经验：
• App 运行在服务器内部 MCP App 不是一个托管的 URL。它是通过 MCP 而非 HTTP 获取的。UI 代码随你的 MCP 服务器一同发布。
• 使用 React 和 Vite
我们使用 React 以复用现有的设计系统。我们在 /ui 文件夹中设置了一个 Vite 项目。在构建过程中，它会为每个 TSX 文件输出一个 HTML 文件。
• 文本仍然是主要的交互契约
如果宿主不支持 MCP App，它会忽略 UI 属性。用户只能看到文本响应。永远不要只在 UI 中提供答案。如果你这样做，使用终端客户端的用户将无法使用你的工具。设计时请始终假设有一半的用户只能看到文本。
• 预料布局的不一致性 每个宿主对规范的实现都不同。ChatGPT 的渲染宽度较宽，Claude 的渲染宽度较窄，移动端则又是另一种情况。从一开始就要设计出能在窄宽度下自动重排（reflow）的布局。
• 开发循环较慢 目前还没有标准的测试工具。你必须在每个客户端手动进行构建、安装和检查。与标准的工程化前端开发相比，这感觉很慢。
• 不要在 App 中收集敏感信息 App 运行在沙箱化的 iframe 中，宿主可以看到其中的内容。永远不要在表单字段中填写 API 密钥或 OAuth 令牌。如果需要敏感数据，请使用独立的加密表单。
如果你现在开始：
- 将 UI 打包在你的服务器中。
- 使用多页面 Vite 配置。
- 直接导入你现有的设计系统。
MCP App 还处于早期阶段，规范也在不断演进。虽然工具链尚不完善，但它们非常值得尝试。
来源：https://dev.to/arcade/lessons-from-building-20-mcp-apps-in-2-days-1f98
可选的学习社区：https://t.me/GyaanSetuAi