多数开发者第一次接触模型上下文协议（MCP）时，直觉上会把整个REST API原样搬过去，觉得让大模型能调用所有接口便是终点。我们一开始也这么想，直到一个压测平台的上百个工具把令牌预算直接击穿，才意识到真正要解决的不是“让模型看得见”，而是“别让模型看见太多”。
我们在OctoPerf上线了一个MCP服务器，背后驱动着一整套负载测试平台，工具数量约100个。负载测试是令牌消耗的极端场景：单个虚拟用户的行为树嵌套极深，一次运行产生的数据轻松达到GB级别，捕获到的一条HTTP响应正文就可能比整个上下文窗口还大。如果简单地给每个接口生成对应的工具，代理会变得昂贵、迟缓且极易被无关数据淹没。上下文窗口成了比API本身更严苛的预算线。
这个预算的压迫感来自三个方向。首先是钱——代理循环中，每个工具返回的结果会作为输入令牌反复计价，一次臃肿的响应会被多次收费。其次是延迟，上下文膨胀直接拖慢模型推理速度，而代理完成一项任务需要串联数十次调用。最隐蔽的是质量衰减：让模型在五万条无关JSON里翻找一个关键字段，准确性会显著下降。这三记重锤让我们决定从一开始就把令牌效率当成架构的第一性约束。
在进入具体模式前，先谈认证——这是被问得最多的部分。整个服务器没有出现任何API密钥。身份验证基于OAuth 2.1，配合PKCE和动态客户端注册（DCR），通过流式HTTP传输。DCR使得客户端可以自行注册，无需手工签发凭证，所有工具调用都以对应关联用户的权限执行，随时可被撤销。我们不想在配置文件里再固化一个长期密钥，尤其是一个具备写入能力的MCP服务器，安全模型必须更谨慎。
第一个关键模式叫做“预签名URL”：把字节数据挡在对话之外。负载测试涉及大量文件的上传与生成——CSV数据集传入，JTL结果、HAR归档、Playwright追踪和PDF报告传出。如果把文件内容塞进工具返回值里，一个2MB的结果文件就会烧掉约50万个令牌，而这些字节对模型几乎毫无价值。所以，所有涉及文件的工具都不直接返回内容，而是返回一套取件指令：一个单次有效的短时效预签名URL，附上HTTP方法和过期时间。代理主机内置的代码解释器（或普通curl命令）直接从REST接口拉取原始字节，模型只看到取件的“说明”，而非文件本身。
这只是打磨令牌预算的第一步。后续我们还引入了响应结构收缩、字段级过滤、懒加载详情等几个策略，确保每次工具调用返回的信息刚好够用，绝不多喂一个多余令牌。下次再有人问起MCP服务器的难点时，可以明确地讲：真正的挑战从来不是连接，而是克制。
热门跟贴