Arcade MCP 认证工具与服务器

问题：手写认证层很脆

在 MCP 生态里，把工具接到需要 OAuth 或 API Key 的上游 API 上，往往意味着自己维护 token 存储、刷新、注入和错误处理。一旦某个 token 泄漏到日志、上下文或模型提示中，后果很难收拾。更麻烦的是，客户端和 LLM 若能看到明文密钥，权限边界就形同虚设。

这个技能做了什么

Arcade MCP 是一个构建 MCP 服务器与工具的 Python 框架。它把认证从业务逻辑里拆出来：密钥由 Arcade 在运行时安全注入到工具调用中，客户端和 LLM 永远不会看到。这样工具可以向上游 API 发起授权请求，而调用方只需关心工具本身的输入输出。

具体能力包括：

• 创建自定义 MCP 服务器，并在其中注册工具；
• 使用 OAuth 感知授权，兼容标准 OAuth 流程；
• 通过 uv run server.py 或 uv run server.py http 选择 stdio 或 HTTP+SSE 传输；
• 支持评估和代理工具调用工作流的部署路径；
• 可选 Arcade Cloud 账户用于托管认证与部署。

框架背后驱动着 7,500 多个预构建工具和 81 个 MCP 服务器，可以作为参考和起点，但不是替代你自己的工具开发。

适用边界与注意点

这个技能适合需要把内部 API 或第三方服务包装成 MCP 工具的团队。它不负责自动生成业务逻辑，也不承诺对任意 OAuth 实现零配置；上游服务的授权范围仍需在 Arcade 中显式声明。

需要留意的是：

• 运行时密钥注入依赖 Arcade 的运行时环境，换部署方式时要重新确认注入链；
• 评估和代理工作流是部署路径的一部分，具体行为取决于上游服务与 Arcade 配置；
• HTTP+SSE 模式会暴露文档地址，适合开发调试，生产环境要结合访问控制；
• 预构建工具数量多，但覆盖范围不等于你的领域需求，仍需自行验证。