Claude Code 接 MCP 有什么用

Claude Code 是 Anthropic 的智能体环境——和「你问一句、它答一句」的聊天机器人不同,它能自己读文件、执行命令、动手改东西,甚至在你走开的时候自己把问题跑完。但默认情况下,它的手只能够到你电脑本地的东西。接上 MCP(一套让 AI 工具调用外部系统功能的连接标准)之后,这只手伸到了你日常在用的系统里:Slack、Google Drive、DocuSign……这正是它从「写代码的助手」变成「能碰你工作流的代理」的那一步。

这篇文章用三个部分讲清楚接上之后到底有什么用:MCP 给 Claude Code 多出来的能力、一个已经跑通的完整参照(法律行业工作流)、以及两条能立刻带走的使用原则。文中所引仓库和文档,以截至 2026 年 8 月可见的版本为据。

MCP 给 Claude Code 加了什么

Claude Code 的默认能力边界在本地:读你的文件、跑命令、改代码。MCP 连接器(connector,负责把外部系统的功能暴露给 Claude 的那层适配)把边界往外推了一层。以 Anthropic 公开的法律工作流仓库 claude-for-legal 为例,里面打包的 MCP 连接器分成两类:通用生产力工具——Slack、Google Drive、Box;法律专业系统——Ironclad、DocuSign、iManage、Everlaw、CourtListener 等。

注意一个细节:这些连接器虽然装在一个法律仓库里,但「通用生产力」那一类本来就是办公场景的通用件,和法律无关。换句话说,「让 Claude Code 去 Google Drive 翻个文件、发一条 Slack 消息、查一下 DocuSign 上这份合同签核到哪一步」,是一般职场用户也能想的事,不需要会写代码。

一个跑通的参照:法律工作流仓库

claude-for-legal 是「MCP 接入后到底怎么干活」现在最完整的公开例子。它是一套面向法律工作流的插件包,覆盖企业法务、隐私、产品、公司事务、雇佣、诉讼、监管、AI 治理、知识产权等方向,外加法学院教学场景。

装法有现成的,不用从零搭。 同一份来源给了两种装法:装成插件(在 Claude Cowork 桌面端或 Claude Code 里),或者通过 Claude Managed Agents API 部署到你自己的工作流引擎后面——后面这条路更适合已经有自己自动化平台的团队。同一个系统提示词、同一套技能,只是运行的地方不同。新手上路看仓库入口的 QUICKSTART.md,照着走大约 60 秒装完;不想碰命令行的话,桌面端是更顺的入口。README 给出的非开发者路径就是这么走的:先装 Claude Desktop,取得 Claude Cowork 访问权,再按仓库里的安装视频一步步操作;全程在桌面端点鼠标,不用碰终端。要在 Claude Code 里接,入口同样是把这个仓库装成插件,而不是从零手写 MCP 服务器配置。

里面实际有什么。 一是按业务领域分的插件,每个都围绕一场「冷启动访谈」构建:装好之后 Claude 先问你几个问题,把你的做事方式(playbook)学进一份 CLAUDE.md 实践档案,之后所有技能都读这份档案——你不用反复教它你的规矩。二是「命名代理」,一整条工作流打包成一个按名字调用的代理:比如 Vendor Agreement Reviewer(供应商协议审阅),用你的模板审一份供应商的 MSA(主服务协议),直接输出标红版本。它的端到端体感是:你用一条命令把它跑起来,它读入 MSA 文件、对照你在冷启动访谈里建立的 playbook,最后把标红版本交回来,中间不用你手动喂文件或拆步骤。三是给「定时盯着看」的流程用的管理代理,比如续约到期监控、案卷动向监控、法规动态订阅。

边界要说清楚,这也是这套插件被设计成这样的原因。 所有输出都只是给律师复核的草稿,不是法律意见;每个引用带出处、对特权事项和主观法律判断默认保守、管辖假设会被显式标出来、对外发送或提交之前有明确闸门。律师负责复核、验证、承担职业责任。插件把复核变快,不替代复核。

原则一:给 MCP 返回的东西一套验证回路

Anthropic 官方最佳实践里最值得带走的一条:Claude 在「看起来做完了」的时候就会停。如果你没给它一个能运行的检查,「看起来做完」就是它唯一的信号,而你就成了验证回路——每个错误都等你发现。反过来,给它一个能产生通过/失败信号的东西,闭环就自己转了:Claude 干活、跑检查、读结果、不行再改。

原文档给过一组很直观的对照。跟它说「实现一个验证邮箱地址的函数」,它实现完就停;改成「写一个 validateEmail 函数,测试用例:user@example.com 应为 true、invalid 应为 false、[email protected] 应为 false,实现后跑一下测试」,它就会自己验证自己。UI 场景同理:把设计稿截图给它,让它实现后截一张结果图对比原稿、列出差异并修掉。

接上 MCP 之后,这条原则的适用范围变大了:检查信号不只有测试套件、构建退出码、lint 这类本地信号,外部系统本身也能出信号。提示词里可以写得更具体:调用 DocuSign 之后,让它把查询返回的签核状态带回上下文,并和你预期的状态核对,而不是只回一句「查过了」;从 CourtListener 拉回案卷更新时,让它把关键字段逐条列出来,说明哪些符合你这次任务要盯的变动。结果回到对话上下文里,它就能自己对照任务要求判断对不对。所以接入任何一个连接器,都值得在提示词里多补一句「做完之后拿什么验证」。

顺带一条通用提醒:上下文窗口(一次会话里 Claude 能装下的全部内容——你发的每句话、它读的每个文件、每次命令输出)是 Claude Code 最稀缺的资源,装得越满性能越差。让外部系统把「有用的结果」灌回来就好,别把原始日志整段拖进来。

原则二:hook 给 MCP 调用装一道门

hooks(钩子)是 Claude Code 的另一层自动化机制(截至 2026 年 4 月文档所示):用户自定义的 shell 命令、HTTP 端点或 LLM 提示词,在会话生命周期的特定节点自动触发。触发点和 MCP 直接相关的是工具调用前后——每次工具调用前(PreToolUse)可以把这次调用拦下来阻止,调用成功后有 PostToolUse、失败后有 PostToolUseFailure,另外还有用户提交提示词时(UserPromptSubmit)、会话开始和结束时(SessionStart、SessionEnd)等节点。文档在高级特性里明确列出了 MCP tool hooks。

这层机制的实际意义:等于给「Claude 用连接器调外部系统」这件事本身装了门卫和收尾。想在调用前拦截、想调用后补一道检查,都不需要改变 Claude 的行为方式,只要在配置里挂上你自己的脚本或接口。写一条 MCP 工具钩子的最小骨架,其实只需要两个要素:一个事件 matcher(例如 PreToolUse)和一个处理命令。文档规定,事件触发时 Claude Code 会把 JSON 上下文通过 stdin 交给命令 hook,你的命令读完上下文就能判断要不要放行——PreToolUse 本身的定义就是「在工具调用执行前触发,可以阻止它」。以拦外部系统调用为例,过滤条件写在命令里:先看工具名是不是 DocuSign、Slack 这类 MCP 连接器对应的调用,是再检查参数和这次调用的意图,要拦就返回阻断决定;不是就直接放行。写成最小示意就是 matcher: PreToolUse, command: check-mcp-call.sh(具体语法以你当前版本文档为准)。

从哪入手:先跑通,再改造

具体配置入口(菜单、命令、配置文件)在各个客户端版本里长得不一样,换代也快——别背任何教程里的命令,动手前先到官方文档确认你当前版本的接入方式。有一点可以作为定位线索:在 Claude Code 里手动接 MCP 时,配置项统一写在 mcpServers 下面;这个文件/菜单在你当前版本里具体叫什么、在哪个位置,以官方文档为准。更稳的起步方式是:别从零搭,先找一个已经封装好的工作流仓库,照着它的 QUICKSTART 跑通,再逐步替换成你自己的场景。上面那套法律插件就是这么设计的:装、跑访谈、让它生成你的实践档案,剩下的事情从「搭建」变成「微调」。