上一篇写了怎么20分钟搭一个MCP Server，发出去之后好几个人问：你那个Server后来还在用吗？用，而且不止一个。那篇只是一个开始。事情是这样的。写完文档搜索Server之后我用了两天，明显感觉Claude Code能做的事变多了，但还不够。查文档是方便了，查完然后呢？该写Jira还是得切出去写，该查线上日志还是得SSH上去tail -f，该触发构建还是得点Jenkins。MCP的能力远不止读几个Markdown文件，但我只用了它最表层的功能。我就想——既然MCP能让Claude Code读文档，那能不能直接调API？不光是读，还要能写。说白了就是让AI能真正操作公司内部系统，而不只是一个高级文档阅读器。然后花了一周搭了三个Server，现在写代码的习惯完全变了。这篇文章就把这三套东西拆开讲讲，有哪些坑、哪些设计思路、哪些现在回头看是多余的。第一个：API网关查询Tool公司后端是微服务架构，几十个服务分布在不同namespace里。排查问题时最烦的是要在各个健康检查页面、监控面板、API文档之间来回跳。明明一行curl就能搞定的事，因为要切窗口、找连接、翻历史，硬生生拖成两分钟的操作。我写了一个MCP Server把内部API网关的查询接口包了一层，Claude Code就去替我curl了：@mcp.tool() def query_service(service_name: str, endpoint: str) - str: """查询指定微服务的状态或端点数据""" import requests url = f"https://internal-gateway.company.io/{service_name}/{endpoint.lstrip('/')}" resp
