北京
今年每个API团队都在收到同样的请求："我们的Agent能调用这个接口吗？"MCP是Agent调用工具的方式，而你手上已经有了一份OpenAPI规范。这两件事之间的距离比以往任何时候都小，所以我花了一个周末，用一份规范跑了七种不同的方案，想弄清楚这个距离到底有多小。
我使用了一份真实的OpenAPI 3.1规范，包含不同类型的端点、API密钥和OAuth2混合认证、分页逻辑，以及几个文件上传端点。换句话说，就是那些会让"傻瓜式生成器"翻车的配置。
基线方案：手写服务器
TypeScript和Python的SDK都很扎实，手写服务器拥有我测试的所有方案中最好的工具描述，因为描述是由人类为LLM读者编写的。
代价很明显：每个工具都要自己写、自己维护。对于精心设计的五个工具面，这是正确答案。对于"暴露我们四十个端点"来说，这是一周的工作量，而且API一变更就开始腐烂。
最适合：小而精的工具面，每个描述都经过精心打磨。
方案二：FastMCP
FastMCP可以直接从OpenAPI规范（或直接从FastAPI应用）构建服务器，开发者体验确实令人愉悦。社区庞大，对Python团队来说是显而易见的默认选择。
它不做的事：托管、认证基础设施或重新生成。部署由你负责，当规范漂移时，重新运行生成并重新部署是你的工作。
最适合：Python团队、内部工具、本地stdio服务器。如果你是这种情况，说实话，不用往下看了，直接用这个。
方案三：开源生成器
规范进，服务器代码出。免费、可检查、输出归你所有，可以自行修改。这是开源纯粹主义者会（正确地）选择的方案。
我遇到的坑：生成工具的描述质量完全取决于你规范里的描述质量。我的描述是几年前写给人类API消费者看的，所以生成出来的工具很模糊，Agent猜得很糟糕。垃圾进，Agent困惑出。这不是生成器的错，但这是大多数真实世界规范的现状。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
