上一篇写了怎么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 = requests.get(url, headers={"Authorization": f"Bearer {SVC_TOKEN}"}, timeout=10)
    if resp.status_code != 200:
        return f"错误{resp.status_code}: {resp.text[:500]}"
    return resp.text[:3000]

这个Tool看起来简单，但有个设计细节很重要——返回值加了三千字截断。一开始我没加，有次查了一个配置量特别大的服务，返回了六万多字的JSON，MCP的返回超限后直接截断不显示。我以为是代码写错了，排查了半天才发现是返回值太大。加上截断之后稳定多了。

配好之后在Claude Code里说「帮我查下订单服务的健康状态」，它自己去调internal API，返回JSON然后整理成可读的文本。

最直接的感受是——调试时不用切窗口了。以前循环是：读报错→切浏览器→找服务地址→curl→看返回→回来改代码。现在变成：读报错→回车→查完→继续改。省掉的不是几秒钟，是注意力切换的成本。写过代码的人都知道，一旦被打断切出去，回来要花好几分钟重新进入状态。这个MCP Server帮我省掉的就是这个切换成本。

第二个：Jira集成

作为开发，每天不知道要开多少个Bug和Sub-task。以前每次都是：切到Jira网页→点Create→选项目→填标题→填描述→选优先级→选assignee→点提交。一套走下来两分钟都算快的，而且极其打断思路。

写了个MCP Tool把Jira REST API包了一下：

@mcp.tool()
def create_issue(project: str, summary: str, desc: str, priority: str = "P3") -> str:
    """在Jira中创建Issue。
    - priority可选P0/P1/P2/P3，默认P3
    - assignee固定为当前API用户，不可更改
    - 注意：Bug必须填写复现步骤到desc参数"""
    import requests
    payload = {
        "fields": {
            "project": {"key": project},
            "summary": summary,
            "description": desc,
            "issuetype": {"name": "Bug"},
            "priority": {"name": f"P{priority[1]}"}
        }
    }
    resp = requests.post("https://company.atlassian.net/rest/api/2/issue",
        json=payload, auth=("bot", TOKEN))
    key = resp.json().get('key', '?')
    return f"已创建: https://company.atlassian.net/browse/{key}"

运行效果比预期好得多。Claude Code遇到异常的时候，我跟它说「把刚才那个报错建个Bug」，它自己提取异常信息、写好标题和描述、选好优先级，直接调了create_issue。整个流程从两分钟缩到五秒钟。

但第一次跑的时候出了个事——我没在参数描述里限制assignee字段。它觉得Bug应该自动分配给项目负责人，就把ticket assign给了主管并且标了P0。凌晨两点主管收到邮件「你有个新的P0 Bug」，点进去一看是AI建的，差点没把我骂死。

第二天被拉到群里解释了一通API Token的权限范围。那之后我每条Tool参数描述里都把能填什么、不能填什么、默认值是什么写得清清楚楚。模型比你想象的更能干——参数列表里多一个字段它就真会用，不一定是好事。

第三个：CI/CD部署日志查询

这个我犹豫了很久——让AI碰部署管线，听起来就像在玩火。一个误操作把生产环境搞挂了可不是闹着玩的。

后来想清楚了：问题是权限控制，不是AI本身。只读查询加上写操作二次确认，风险就可控。真正让我决心做的，是查日志这个痛点实在太频繁了。

@mcp.tool()
def query_deploy_logs(service: str, lines: int = 50) -> str:
    """查询指定服务最近的部署日志（只读操作，不会触发任何部署）"""
    import subprocess
    result = subprocess.run(
        ["kubectl", "logs", "-n", "production", "-l", f"app={service}",
         "--tail", str(lines)], capture_output=True, text=True, timeout=15
    )
    return result.stdout[-3000:] if result.stdout else result.stderr[:1000]

@mcp.tool()
def trigger_deploy(service: str, branch: str = "main") -> str:
    """触发指定服务的部署。重要：请先调用query_deploy_logs确认当前版本，
    再明确目标环境（staging或production），然后再执行部署。
    此操作不可逆。生产环境部署请谨慎。"""
    return "请先查日志确认当前版本和状态，确认环境后再调用此函数。"

trigger_deploy这个Tool其实是个「假触发」——它的流程是强制模型先查日志、再确认环境、再三考虑后才真执行。算是一种软件层面的人肉确认机制。

真正让我觉得一周时间花得值的，是线上日志查询能力。以前出问题的流程：看到报警→打开Kibana→选时间范围→构造查询语句→翻结果→定位代码。运气好一分钟，运气不好五分钟以上。

现在一句话「查下单接口最近五分钟的错误日志」，Claude Code自己调日志Tool，把堆栈和上下文贴出来。配合代码上下文，它甚至能直接告诉我哪个文件哪行代码可能有问题。这不光是省时间，是省掉了从日志到代码之间的推理跳跃。

一点意外收获

这套东西搭完之后有个意料之外的用途——新人onboarding。团队来了个新同事，以前要花一整天教他怎么查服务状态、怎么建Bug、怎么看日志。现在直接给他配好MCP配置文件，他对着Claude Code说自然语言就能完成大部分操作。不需要先学会公司那一套工具链的用法，会说话就行。上手曲线直接平了一半。

这也让我意识到MCP的真正价值不只是在"让AI更强大"，而是在于把公司内部的操作知识从人脑里抽出来，变成模型能理解的结构化信息。每个Tool的参数描述和docstring，其实就是一份可执行的操作手册。新人不用再翻Wiki了，模型替他查。

一周后回不去了

不是说Claude Code替代了所有工具，而是它让我不用在六七个Tab之间来回切换了。五个Server挂在那里，写代码时它们就在后台，需要时自动被调用。写了一段时间之后我甚至开始不自觉地依赖这个机制——遇到问题第一反应不是去翻文档，而是直接在Claude Code里描述问题让它去查。这个习惯的转变本身说明了一切。

MCP最聪明的地方不是协议有多深，而是它把接口公开了——你想接什么系统，写几百行代码就行。每接一个，日常操作就少了一个环节。以前是「等会我去查一下」，现在敲一句话的事。当然偶尔也会翻车，比如那次凌晨两点的P0乌龙，但翻一次之后把参数描述写清楚，后面再也没出过问题。翻车不可怕，可怕的是没有在翻车之后把车修好。

如果你也在考虑搞MCP Server，我的建议很简单：从最让你烦的那个操作开始。不是接一个牛逼的系统，是接一个你每天要重复五遍的破事。省出来的不光是时间，是反复被打断再重新进入状态的那种烦躁感。先把最痛的那个点解决了，自然就有动力接第二个了。别想一口气搭完所有系统，一个一个来，搭一个就少一个烦心事。回头看看这一周做的事，其实就是把那些日常要切出去操作的环节一个一个消灭掉，留下的只有写代码本身。