RESTk+MCP实测：AI Agent直接操作你的API客户端

当API客户端开始"长"出一个AI队友

API调试工具长期停留在"人操作界面"的阶段——手动建集合、逐个发请求、肉眼对比响应。RESTk试图改变这个交互模型：它在你的Mac上运行一个私有的MCP Server，让Claude Code、Cursor、Windsurf等支持MCP协议的AI助手直接接入，把API客户端的40多项能力变成Agent可以调用的工具。

这套方案的逻辑并不复杂：与其让AI生成代码再由人去API客户端里执行，不如让AI直接"住进"API客户端。官方演示给出了一个完整的审计场景——AI自动检查10个文件夹中43个请求的方法名与实际HTTP方法是否匹配，发现并修复了一个真实bug。

MCP Server如何连接你的AI助手

一键接入，多客户端通用

设置入口在Settings的AI Integration面板。MCP Server状态显示Ready后，选择你的助手——Claude Code、Claude Desktop或Cursor，系统会生成对应的配置文件，同时提供终端可用的复制粘贴命令。Windsurf、ZED、VS Code搭配Continue等任何MCP兼容助手，理论上都能接入同一个Server。

这种设计的价值在于解耦：RESTk提供工具层，AI助手提供推理层，用户不必被锁定在某一家的AI产品里。

在设置中配置MCP Server连接

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底开源的协议，用于标准化 AI 助手与外部工具、数据源之间的连接方式。可以把 MCP 理解成 AI 世界的「USB-C 接口」：过去每接入一个新工具，AI 客户端都要为其单独写适配代码；有了 MCP 之后，工具方只需实现一个 MCP Server，暴露若干「工具（tools）」（每个工具包含名称、描述和 JSON Schema 参数定义），任何支持 MCP 的客户端——Claude Code、Cursor、Windsurf、ZED、VS Code + Continue 等——都能通过统一的 JSON-RPC 调用这些工具。协议还支持 resources（可读取的数据）和 prompts（预置提示模板），并可选支持 sampling（Server 反向请求 AI 生成内容）。这正是 RESTk 能「一次实现、多家通用」的底层原因，也解释了为什么它不必为每个 AI 助手单独开发插件。

默认零共享，权限从零开始

连接成功后第一件事可能会让人困惑：问Claude"我有多少个集合"，答案是零。这不是bug，而是设计选择——在你主动开启"Share with AI"之前，任何集合都不会暴露给AI。RESTk甚至会告诉助手需要打开哪个开关。

共享是逐个集合进行的。开启后AI能浏览和发送请求，但真实密钥始终不可见——它们被合成数据替换。即便AI反复请求，它看到的也只是"磁盘上有什么"，而非"密码是什么"。

文中提到的「合成数据替换真实密钥」，在安全工程中称为 凭据脱敏（credential redaction） 或 数据掩码（data masking）。其要点在于：AI 看到的请求体里，Authorization、api_key、password 等字段会被替换成结构相同但无实际价值的假值（如 sk-xxxx、Bearer <redacted>），从而既能让 AI 理解请求结构、完成审计与文档生成，又避免真实密钥进入模型上下文。这一步非常关键，因为一旦密钥进入 AI 的上下文窗口，就可能被写入日志、被后续 prompt 泄露，或随模型提供商的数据策略流出。相比「事后删除」，「默认替换」是一种前置的架构约束——不依赖 AI 合作，也不依赖用户记得清理。

一个真实的API审计案例

AI发现方法名与实际请求不一致

演示中最能说明问题的是一个审计任务：检查HTTP协议覆盖集合中，每个请求的名称是否与其实际发送的HTTP方法匹配。

Claude调用RESTk的工具遍历了全部10个文件夹，检查了43个请求，找到一个真实bug——一个名为"get"的请求实际上发送的是PUT方法，并且附带了Basic Auth自动发送，这在Basic Auth场景下不应该发生。其余42个请求全部通过检查。

AI遍历10个文件夹完成43个请求的审计

变更前审批，可撤销，凭据全程脱敏

发现bug后让AI修复，RESTk会先弹出审批界面展示具体变更内容。允许后PUT改为GET，多余的认证头被移除。Claude还解释了它选择不碰哪些内容以及原因。

如果嫌每次审批繁琐，可以开启auto-approve，但删除操作、裸HTTP调用和preset运行仍然需要人工确认。演示中还让AI撤销了修改，证明所有操作可逆。整个过程中，用户名和密码从未出现在AI的上下文里——它们全程被redacted。

变更审批与执行完成

Human-in-the-loop（人类在环）审批 是当前 AI Agent 落地的常见安全模式：Agent 提出的每一项有副作用的操作（写入、删除、发送真实请求）在执行前都需人工确认。RESTk 在此之上做了两级设计——默认逐项弹窗审批，用户可选开启 auto-approve 提高效率，但删除操作、裸 HTTP 调用和 preset 运行三类高风险动作仍强制人工确认。这里的「裸 HTTP 调用」指不经过集合/环境约束、直接向任意 URL 发送请求的能力，若被 AI 自主调用，可能被诱导访问内网地址（SSRF）或外泄数据，因此单独设卡。审批本身配合 Git 版本控制，形成「可审批 + 可回滚」的双重保障。

不止于调试：文档生成与Agent就绪度评估

让AI为整个集合写文档，它会分批为43个端点生成描述，每份草稿都经过密钥泄露检测和端点存在性验证。生成的文档不只是人类可读的描述，还包含面向其他AI Agent的结构化指引：何时使用、前置条件、后续步骤、何时不该用。

集合页面（如Quick Start和Authentication）需要你的审核才会被接受。最终可以预览为完整的文档站点，真实值自动脱敏。

预览自动生成的文档站点

因为RESTk将所有内容存储为纯文件，AI的每次变更都会落入Git，你可以正常review、commit和push。此外，AI助手还能对API进行7个维度的Agent就绪度评分、执行安全审计、从Postman或OpenAPI导入集合。支持MCP sampling的助手，还可以在响应查看器里直接让AI解释错误或生成测试用例。

Agent 就绪度（Agent readiness） 指一套 API 是否容易被自主 AI Agent 正确理解和调用。人类开发者能通过浏览器试错、看示例、读报错来推断 API 用法，但 Agent 没有这种交互余地，它依赖的是结构化、明确、无歧义的元数据。评估通常涵盖：端点描述是否清晰、参数类型与必填性是否标注、认证方式是否说明、错误码是否有语义、是否有使用前置条件与副作用提示、是否有速率限制说明等。RESTk 把评分细化为 7 个维度，本质上是在把「API 文档能否面向机器阅读」这一模糊问题量化——这也是 OpenAPI 描述质量、LLM 工具调用成功率之间的直接桥梁：描述越结构化，Agent 的调用准确率就越高。

安全性架构分析

RESTk的安全模型可以归纳为几层：Server仅本地运行、集合默认不共享、共享后真实值替换为合成数据、变更需审批、AI审计标签页记录AI看到了什么。

这套设计的核心假设是：AI是有用的但不可完全信任。因此不依赖AI"自律"，而是通过架构约束——脱敏、审批、本地运行、Git可追溯——来限定AI能做什么。对于在API调试中处理生产环境凭据的开发者来说，这种"默认不信任"的设计思路值得参考。

MCP协议正在成为AI助手连接外部工具的事实标准之一。RESTk的实践展示了一种可能性：传统开发工具不必重写为AI原生应用，只需通过MCP暴露工具接口，就能让现有的AI助手获得操作能力。