mcp-builder

使用 mcp-use 构建

将已安装的 mcp-use 包、其导出的类型、生成的声明文件以及项目现有代码视为事实依据。选择 API 或修改代码前，先检查已安装的版本。

工作流

1. 检查 package.json、服务入口、导出的工具引用、mcp-env.d.ts、views/、skills/ 以及已安装的 mcp-use 版本。
2. 使用 create-mcp-use-app@latest 和适当的模板搭建新的稳定版项目。开发 beta、canary 或已有版本的项目时，匹配相应的包版本或 dist-tag。
3. 只阅读任务所需的参考资料：
   • 服务端：了解工具、资源、提示词、MCP 中间件、请求上下文和结果封装。
   • 视图：了解交互式 MCP Apps、React hooks、模型上下文、宿主能力、资源文件和 CSP。
   • 身份验证：了解 OAuth 提供方、已验证身份、作用域、权限和授权。
   • 当服务端需要随工具一同提供可复用工作流时，阅读 通过 MCP 提供的 Skills。
   • 高级功能：了解 OpenAPI、代理、通知、订阅和信息收集。
   • 仅当存在已弃用或仅为兼容而保留的导入、辅助函数、注册形式、UI 模式或会话假设时，阅读 迁移。
   • 在报告实现工作完成前，阅读 验证。
4. 根据已安装的类型进行实现。优先采用框架当前的惯例，而非照搬示例或历史更新日志。
5. 验证能够证明行为变更的最小真实生命周期，然后根据风险适当扩展检查范围。

核心不变量

• 从 mcp-use 导入服务端 API，从 mcp-use/react 导入 React API，从 mcp-use/oauth/* 子路径导入 OAuth 提供方适配器。
• 使用 inputSchema 定义工具参数。对于结构化结果以及每个绑定 View 的工具，都要添加 outputSchema。
• 返回原始 MCP 结果封装。使用架构的工具成功时必须包含匹配的 structuredContent；预期失败时可返回 isError: true，并附带模型可读的 content。
• 将每个 View 放在 views/<name>/view.tsx，并使用 view: { name: "<name>" } 绑定。
• 导出 View 使用的所有静态声明工具引用。默认导出供 mcp-use dev、build 和 start 使用的服务入口。
• 将身份信息和可变工作流状态限定在请求范围内，或存储在外部。将客户端报告的元数据视为未经验证的数据。
• 如果服务端提供了可重复的多步骤工作流，否则会导致工具描述过长，请考虑通过 MCP 提供 Skills。

防护规则

• 不要臆造导出项、配置字段或回调形式。遇到不确定的细节时，应在已安装的声明文件或源码中确认。
• 不要仅因为某些 API 出现在现有项目中，就保留已安装版本中不存在的 API。
• 不要从工具回调返回普通领域对象。
• 不要在缺少匹配的 outputSchema 和 structuredContent 结果时绑定 View。
• 不要使用模块级全局变量存储跨请求身份信息、信息收集的连续状态或持久业务状态。
• 如果类型、包导出、身份验证或交互行为发生了变化，仅凭源码构建成功，不要宣称实现成功。
• 除非用户明确要求，否则不要部署或修改外部系统。