做 MCP 集成时,先别问框架够不够强。先问用户到底需要看见什么、批准什么、出错后从哪里恢复。
先选最小表面
如果你的目标只是把工具、资源或 prompt 暴露给现有客户端,普通 MCP Server 通常就够了。它更容易检查、测试和替换。
只有当工作流需要可见 widget,比如图表、地图、文件浏览器、进度面板,或用户必须先看见状态再决定下一步时,MCP App 才更合理。
- Server:主要价值是工具或数据访问。
- App:用户需要一个可见的决策界面。
- Client / Agent:你的产品要主动编排其他 MCP servers。
用 mcp-use 当参考栈
mcp-use 的价值在于官方 README 和文档把多个 MCP 表面放在一起:TypeScript/Python server SDK、带 React widget 的 MCP Apps、Inspector、部署工具,以及 agent/client libraries。
这很适合拿来做比较,但不代表一上来就要全栈采用。你需要把每个能力映射到真实用户动作,而不是因为它存在就加进去。
开工前检查
- 先写清 host:ChatGPT、Claude、内部工具,还是自己的产品。
- 写清用户在下一步前必须看见或批准的动作。
- 写清会碰到哪些数据、凭证或外部账号。
- 写清日志、错误、重连状态、OAuth 失败从哪里检查。
- 先验证 server 路径;没有可见决策损失时,不急着加 widget。
什么时候别做 App
如果只是内部自动化、一次性脚本,或只返回结构化数据的工具,先跳过 App 层。widget 不能让决策更安全时,只会增加 auth、状态和支持成本。
来源
- mcp-use·官方资料·核心来源mcp-use GitHub repository
- mcp-use·官方资料·核心来源mcp-use documentation
- mcp-use·官方资料·辅助来源mcp-use releases
