Claude Code 入门：用 MCP 让 AI 走出代码仓库

为什么需要 MCP：让 AI 真正接入你的技术栈

在实际开发中，像一个 Issue Tracker（问题追踪）这样的应用，开发者最理想的状态是：别人不必通过 UI 界面，就能直接使用它的功能。尤其在 AI 大量普及的当下，很多人更希望通过 AI 来与自己的后台系统交互，而不是手动点击操作。

Lydia 在这期 Claude Code 综合入门教程中给出的核心答案，就是 Model Context Protocol（模型上下文协议，简称 MCP）。

在接触 MCP 之前，我们对 Claude Code 的使用大多局限在代码仓库（repo）内部——编辑文件、运行命令、阅读代码。这些操作本质上都没有跳出 repo 的边界。而 MCP 的价值在于：它是一套协议，能让 Claude「伸手到仓库之外」，去真正与你整个技术栈的其余部分交互。

MCP 到底是什么：AI 工具的标准接口

从技术定位上看，MCP 本身只是一种协议——一种特定的服务端协议类型，位于客户端（clients）和你的后端（backend）之间。它的核心思想非常朴素：为 AI 工具提供一个标准化的接口。

要理解它的意义，需要回到问题的起点。此前每个工具都在各自造轮子、搞自己的集成方案。比如你想集成 Linear，到底该怎么做？直接调用它的 API 吗？不同工具各有各的接法，缺乏统一规范，集成成本极高。

MCP 做的事，就是把这件事在 Anthropic、Cursor 以及其他众多工具之间统一标准化。换句话说，它扮演的角色类似于「AI 领域的通用插口」。

Lydia 特别提到一个曾困扰她的疑问：既然要调后端，为什么不直接用 REST API？答案是——MCP 并不是要取代 REST API 的技术功能，而是作为 AI 交互的标准范式 存在。这是一个认知上的关键转变：你不是在为传统客户端设计接口，而是在为 AI 设计一个它能理解和调用的统一入口。

从历史背景来看，MCP 由 Anthropic 于 2024 年 11 月正式发布并开源。它借鉴了 USB-C 这类通用物理接口的设计哲学——在此之前，每个 AI 应用都需要为每个外部数据源或工具单独编写定制化的集成代码，M 个模型对接 N 个工具就需要 M×N 套集成方案。MCP 将其简化为 M+N：工具方只需实现一次 MCP 服务器，模型侧只需实现一次 MCP 客户端，双方即可互通。协议基于 JSON-RPC 2.0 构建，支持三种核心能力暴露方式：Tools（AI 可主动调用的函数）、Resources（AI 可读取的数据源）和 Prompts（预定义的提示模板）。目前 Cursor、Zed、Claude Desktop 等主流 AI 开发工具均已支持 MCP 客户端，生态正在快速形成。

MCP 在真实场景中的样子

想直观感受 MCP 的运作，可以观察使用 Claude AI Chat 时的行为。当你让它「画一个 Excalidraw 图形」时，它并不是直接去调用某个 Excalidraw 的 REST API 或后端，而是调用对方提供的 MCP。

这个例子揭示了 MCP 的运行逻辑：AI 作为客户端，通过标准协议向外部服务发起调用，服务方只需按 MCP 规范暴露自己的能力，AI 就能自动理解并使用。双方不再需要为每一次集成单独约定接口细节。

动手构建：MCP SDK 与工具注册

在实际开发层面，Lydia 推荐了一个非常实用的 NPM 包——Model Context Protocol SDK。她表示，自己构建任何 MCP 服务器时，用到的大部分能力都来自这个 SDK。

这个 SDK 提供了几个关键原语（primitives）：

• 创建服务器（server）：搭建一个 MCP 服务的基础骨架
• 注册工具（register tools）：把你的后台能力封装成 AI 可调用的工具
• 连接传输层（transport）：通过 server.connect 把服务器接入某种传输通道

工具注册的完整流程

以一个「列出问题列表」的工具为例，注册一个 MCP 工具通常包含以下几个要素：

1. 名称（name）：这里命名为 list issues，让 Claude 知道有这样一个工具可用
2. 描述（description）：清楚说明这个 MCP 工具能做什么——这一步对 AI 正确调用至关重要，因为 AI 要靠描述来判断何时该用它
3. 处理函数（handler）：定义当 Claude 调用这个工具时，实际应该执行什么逻辑

处理函数执行完后，需要返回 MCP 所期望的内容类型。在这个例子中，返回的是一个 content 数组，类型为 text，内容则是把这些 issues 序列化（stringify）后的文本。

最后一步，是把服务器连接到传输层。示例中使用的是 stdio server transport，这样 Claude Code 才能真正与这个 MCP 服务器建立通信。

在传输层选择上，MCP 支持两种主要传输机制：stdio（标准输入输出） 和 SSE（Server-Sent Events，服务器推送事件）。stdio 传输是本地场景的首选，Claude Code 通过启动一个子进程并通过标准输入输出与其通信，适合在同一台机器上运行的工具；SSE 传输则适用于远程服务器场景，允许通过 HTTP 长连接与部署在云端的 MCP 服务通信。示例中使用 stdio server transport 正是为了配合 Claude Code 本地运行的工作方式——Claude Code 在本地启动你的 MCP 服务器进程，通过 stdio 管道与其交换 JSON-RPC 消息，整个过程无需额外的网络配置。

工具描述（description）的质量直接决定 AI 能否在正确的时机调用正确的工具，这一点在实践中往往被低估。由于 AI 完全依赖描述来理解工具的用途和适用场景，描述应清晰说明：该工具做什么、接受哪些参数、何时应该使用它、返回值的含义。除了文字描述，工具的输入参数通常通过 JSON Schema 定义，指定每个参数的类型、是否必填以及含义说明——这相当于给 AI 提供了一份「调用说明书」，使其能够在推理过程中自动构造符合格式要求的调用请求，而无需人工干预。

小结：MCP 带来的开发范式转变

MCP 的意义不在于它引入了多么复杂的新技术，而在于它为「AI 调用外部能力」这件事确立了统一标准。对于开发者而言，这意味着：

• 你的应用可以不只服务于人类用户，还能成为 AI 可直接调用的服务
• 过去碎片化、各自为政的集成方式，被收敛到一套通用协议之下
• 借助 MCP SDK，把现有后端能力包装成 AI 工具的门槛大幅降低

对于想让自己的产品搭上 AI 浪潮的开发者和创业者来说，理解并实现 MCP，正在成为一项基础能力。