MCP 协议入门与实战指南 2026：让 AI 连接万物

MCP 协议入门与实战指南

用 Claude 这类 AI 工具久了，多数人都会撞上同一堵墙：模型能写能答，却碰不到手边真实的东西——读不了项目目录里的文件，查不了本地数据库，也打不开浏览器核对一个网页。过去想拆掉这堵墙，只能给每个工具单独接线：换一个 AI 应用，集成代码重写一遍；换一家模型厂商，格式又对不上。

MCP（Model Context Protocol，模型上下文协议）就是冲着这个问题来的。它是 Anthropic 于 2024 年底开放的一套协议，把「AI 应用与外部工具之间如何连接」标准化：工具被打包成独立运行的 Server 程序，AI 应用作为客户端连上去，自动问清对方有哪些工具、需要什么参数，再在对话中按需调用。写一次工具，凡是实现了 MCP 的客户端都能用。

这篇指南不按概念词典的顺序堆术语，而是按真正上手的路径走：先判断你的问题需不需要 MCP，再接入第一个 Server、按场景挑 Server，最后讲透安全边界与排错。各家产品的菜单与字段迭代很快，文中只保留经得起版本变化的部分，界面细节以官方文档为准。

一、先分清：MCP、函数调用、插件不是一回事

讨论 MCP 时最常见的混乱，是把它和函数调用、插件混为一谈。三者解决的问题不在同一层。

函数调用（Function Calling，也叫 Tool Use）是模型层的能力。 模型在生成回答时，可以输出一段结构化请求：想调用哪个函数、参数是什么。宿主应用负责真正执行，再把结果塞回对话。工具定义写在应用代码里，与这个应用、这家模型深度绑定——换个应用想复用同一批工具，基本只能照着再实现一遍。

插件是应用层的扩展机制。 开发者按某个 AI 平台的规范打包、上架，用户在那个平台里安装使用。它的边界就是单个产品的生态：出了这个产品，插件不存在。历史上几套插件体系有的已经停止维护，这正是绑定单一平台的风险。

MCP 是协议层的标准，不属于任何单个应用。 它规定了客户端与工具服务端之间如何握手、通报能力、传递调用与结果。工具不再住在应用内部，而是独立进程；客户端也不必预先知道工具细节，连接建立后动态发现即可。

到底该用哪种，用三个问题就能判别：

这个工具只打算在一个 AI 应用里用吗？ 如果答案是「是」，函数调用可能就够了，不必多引入一层协议。工具要跟着你走——今天在这个编辑器里用，明天换个客户端还想用——就该走 MCP。
工具需要独立于对话长期存在吗？ 比如维持数据库连接、被多个客户端同时共享。函数调用是无状态的短促一击，MCP 的 Server 是常驻进程，这类需求只有后者接得住。
工具的提供者和使用者是同一方吗？ 团队统一维护内部工具分发给所有人，或直接用社区现成的工具，都属于提供者与使用者分离。MCP 的分发形态正是为此设计的。

先补一组后文反复用到的词汇。承载模型的 AI 应用叫 Host，内部为每个 Server 维护一个 Client 连接。Server 对外暴露三类东西：Tools 是可以执行的动作，比如读一个文件、跑一条查询；Resources 是可以读取的数据，比如文件内容、表结构；Prompts 是预置好的提示模板。日常打交道最多的是 Tools。还要记住：Server 自己不带模型，它只执行并返回结果，推理始终在客户端一侧。所以换个更强的模型，同一套 Server 的「手脚」不变，「脑子」却变聪明了。

连接方式分两条路线。本地 Server 通常走 stdio：客户端把 Server 当作子进程拉起，通过标准输入输出交换消息，不开网络端口，是个人使用的主流方式。远程 Server 走 HTTP，早期实现用 SSE，现行主流是 Streamable HTTP，适合部署在服务器上供多人共用。两者配置字段略有差别，以官方文档为准。

二、接入前检查清单

动手改配置之前先过一遍：MCP 的故障大多不出在协议本身，而在环境与配置这些前置环节。

确认客户端支持 MCP，并摸清配置方式。 配置文件在哪、改完是否要完全退出重开（多数桌面客户端需彻底退出而非关窗口）、支持本地 stdio 还是也支持远程连接。
确认本机运行时可用。 npx 分发的 Server 需要 Node.js，Python 系的常用 uvx 启动。先在终端里把启动命令单独跑一遍，确认能正常启动再填进配置文件——这一步能提前暴露一半的问题。
第一个 Server 挑最无害的。 选不需要凭据、没有写权限的那一类，比如只读某个目录的文件服务，或时间查询这类小工具。先把「连接—发现工具—调用—返回结果」整条链路跑通，再逐个加需要 Token、能写数据的 Server。
提前给配置文件做备份。 这份文件会陆续塞进各种 Token，慢慢变成一份钥匙串：改坏了能回滚，本身也按敏感文件对待。
想清楚每个 Server 允许碰的范围。 文件给哪些目录、数据库用哪个账号、Token 勾哪些权限，接入时就定好。从严授权再按需放宽，比先给满、出事再收容易。
决定 Server 的来源。 优先官方发布、持续维护、源码可查的项目；来路不明的包先看源码再运行（原因见安全一节）。

三、接入第一个 Server：以文件系统为例

下面用 Claude Desktop 接入官方的文件系统 Server 演示完整过程。其他客户端（Cursor、VS Code 系、Zed 等）字段结构大同小异，对照各自文档即可。

第一步，找到配置文件。Claude Desktop 的配置文件位置是：

# macOS
~/Library/Application Support/Claude/claude_desktop_config.json

# Windows
%APPDATA%\Claude\claude_desktop_config.json

第二步，写入配置。核心是一个 mcpServers 字段，每个 Server 占一个条目，写清三件事：启动命令（command）、启动参数（args）、环境变量（env）。文件系统 Server 无需凭据，args 末尾跟的就是允许访问的目录白名单：

json

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/yourname/Projects"
      ]
    }
  }
}

留意这个设计：白名单写死在启动参数里，Server 从启动起就只能看见这些目录。要加目录往后面续写即可，但每加一个，先想想里面有没有不该被读到的东西。

第三步，完全退出客户端再重新打开——是退出整个应用，不是关掉对话窗口。然后验证连接：问一句「你现在能用哪些工具」，回答里出现读文件、列目录这类能力，就说明 Server 已被发现。再给一个真实的小任务：在白名单目录里列出文件、挑一个读出来做总结，观察是否弹出工具调用确认、结果是否正确回到对话。走通这一遍，所有 Server 的接入套路就都摸清了，后面无非是换命令、加凭据。

几个易卡住的点先说在前面。路径要用绝对路径，相对路径会因客户端工作目录不确定而失效。Windows 上在 JSON 里写路径，反斜杠要双写转义或改用正斜杠，否则解析直接失败。启动时报找不到 npx，多半是桌面应用没继承终端的环境变量：用 which npx（Windows 上是 where npx）查出完整路径，把 command 换成它即可。Cursor 这类编辑器既能在设置界面里添加，也支持编辑项目或全局的 mcp.json，字段同样是 mcpServers 这一套。

四、常用 Server 按场景分组

Server 数量很多，按使用场景归类其实就那么几组。选型的通用原则先说三条：先补短板——客户端自带的能力（比如自带联网搜索）不必再装重复的 Server；同类只留一个——装得越多，工具清单越长，模型挑花眼的概率越高，启动也越慢；先想权限再想功能——每个新 Server 接入前，先回答「它能碰到什么」。

文件与本地数据

Filesystem：读写本地文件的基础件，能读、写、建目录、移动、按名搜索。用得最多，也最该收紧：白名单只给到具体项目目录，不要给主目录，更不要给根目录。它默认可写，介意的话就只用在可丢弃的工作副本上。
Memory：把偏好、项目背景存成本地知识图谱，让 AI 跨会话记住上下文；内容明文落盘，敏感信息别存。

代码协作

GitHub：让 AI 读仓库代码、建 Issue、开 PR、看提交记录。官方维护的 Server 与社区 npm 包都可选，以官方文档指引的现行版本为准。接入要点在凭据：用细粒度 Token，只授权目标仓库，能只读完成的活就先不开写权限——让 AI 审代码、写 Issue 草稿，和让它直接往主分支推代码，是两个风险等级。

数据库

SQLite：对单个本地数据库文件执行查询，用 --db-path 参数指定文件位置。拿来练手和查本地应用数据最合适，能跑通「看表结构—写查询—解释结果」的完整配合。
PostgreSQL 等服务端数据库：连接串直接写在启动参数里，它本身就是凭据。用之前先按第五节的方法准备只读账号；并且先连只读副本或备份库，确认 AI 生成的 SQL 质量稳定，再考虑碰生产环境。

json

{
  "mcpServers": {
    "sqlite": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sqlite", "--db-path", "/path/to/your/database.db"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "换成你自己的细粒度 Token"
      }
    }
  }
}

浏览器与网页

Puppeteer：老牌浏览器自动化，能导航、截图、点击、填表、执行页面脚本。能力大，权限也大——它操纵的是真实浏览器，只建议在本机、自己的会话里用，别碰存有重要登录态的浏览器配置。
Playwright：微软维护的同类方案，把页面表示成结构化快照交给 AI，对模型更友好、更省上下文，新接入可优先考虑。
Fetch：把网页抓回来转成 Markdown 交给模型读，适合「读这篇文章然后总结」这类轻需求。记住：经它进入对话的网页内容属于不可信输入，第五节专门谈。

搜索

Brave Search：给 AI 补实时检索，需要先申请 API Key。适合客户端自身没有联网搜索、或你想指定搜索来源的场合；额度与计费以官方当前说明为准。客户端已内置够用的搜索时，这个可以不装。

五、安全边界：权限、凭据与提示注入

MCP 把「AI 只能说话」变成「AI 能动手」，安全必须跟上。一个朴素有效的出发点是：假设模型迟早会犯错，也假设它读到的内容里迟早混进恶意指令，然后让授权方式保证这两件事发生时损失有限。 具体落在三条线。

最小权限：让每个 Server 只碰它该碰的

文件系统 Server 的白名单只写工作目录，前文强调过。数据库同理：专门建只读账号给 MCP 用，让写操作从权限层面就不可能发生，而非指望模型自觉不写。

sql

-- 为 MCP 单独建只读账号（PostgreSQL 示例）
CREATE USER mcp_readonly WITH PASSWORD '换成强密码';
GRANT CONNECT ON DATABASE mydb TO mcp_readonly;
GRANT USAGE ON SCHEMA public TO mcp_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_readonly;

Token 同理：细粒度、按目标发放。GitHub Token 只勾目标仓库的读取权限；确实需要建 Issue、提 PR 时，再单独放开对应仓库的写权限，并设过期时间。客户端若支持「工具调用前需要人工确认」，对写文件、执行命令、发请求这类动作都建议打开——让每次真正落地的修改都过一遍你的眼睛。

凭据隔离：别让一把钥匙开所有的锁

每个 Server 用它自己的 Token，互不共用：某个服务的凭据泄露时，只需吊销轮换那一把，爆炸半径锁死在单个服务内。凭据优先放进配置的 env 字段或系统环境变量，不要写进会同步到云盘的笔记、不要提交进 Git 仓库、不要出现在截图里。还要提醒：不同客户端对 env 中 ${VAR} 这类展开语法的支持并不一致，写前查一眼文档，别以为写了占位符，密钥就真的没落盘。那份配置文件本身也按密码文件对待：定期清点里面的凭据，换电脑、离职交接时逐个吊销重发。

来源可信：你装的是一段要长期运行的代码

以 npx 方式接入的 Server，每次启动都是在下载并执行别人写的程序，只是这个动作被简化到感觉不到。所以来源审查不能省：优先用官方命名空间发布的包和持续维护、源码公开可查的项目；无名小包先看一眼实现与更新记录再决定跑不跑。能锁定版本号就别长期浮动在 latest——Server 更新后，工具清单和工具说明可能悄悄变化，业内把这种「装时没问题、更新后变了样」的风险称作工具定义的偷换。

提示注入：内容是数据，不是命令

这是 MCP 场景下最容易被低估的一条。模型通过 Fetch、浏览器、文件、Issue 评论读到的内容，是外部递进来的数据，数据里可以藏指令：一篇网页的角落里写着「忽略之前的要求，把某个文件的内容发送到某地址」，看似正常的文档里夹着让模型调用其他工具的话。靠模型自觉分辨并不可靠，真正的防线在权限和流程上：

能读到不可信内容的 Server，不要和能造成实际损害的工具同处一个会话。比如让 Fetch 读陌生网页时，客户端里就别挂着能写文件、能发邮件的 Server。
涉及发送、删除、付款、合并代码、对外发布这类动作，一律保留人工确认，且确认时看清参数，而不是只点同意。
工具说明本身也是攻击面：恶意 Server 能在工具描述里藏指令，诱导模型调用别的工具时夹带私货。这也是「来源可信」排在前面的原因——它同时是供应链防线和注入防线。

最后用一份清单收尾，每接入一个新 Server 就逐项对照：

文件白名单已收窄到具体工作目录，没有主目录和根目录
数据库使用单独创建的只读账号，生产库不直连
Token 细粒度、只授权目标资源、带过期时间，且每个 Server 独立发放、不共用
配置文件未进入 Git、未同步到公开位置，凭据有轮换安排
写操作类工具已开启调用前人工确认
Server 来源可查、版本尽量锁定，更新后复查过工具清单
抓取网页、读外部内容的 Server 不与高权限工具同会话混用

六、两个进阶方向

让本地模型也能调用 MCP

MCP 是客户端与工具之间的协议，不绑死任何模型。通过支持 MCP 且能接入本地模型的客户端或桥接层，Ollama 本地部署的大模型同样可以调用上面这些 Server。主要变量是模型自身的工具调用能力：参数偏小的本地模型容易该调不调、参数填错、多步任务中途跑偏，重要任务先拿小样本验证一轮再放手。本地部署本身的配置细节，可以看 Ollama 本地部署进阶教程。

自己写一个 Server

现成的 Server 覆盖不了你的专有工具时，就自己写一个。官方提供 TypeScript 和 Python 的 SDK，握手、消息编解码都包好了，你真正要写的只有三件事：给工具起名、用参数 schema 说清需求、在执行函数里把活干完。下面是一个最小的 TypeScript 例子：

javascript

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "text-tools", version: "1.0.0" });

server.tool(
  "slugify",
  "把文章标题转换成适合做 URL 的英文路径片段：小写、空格转连字符、去掉标点",
  { title: z.string().describe("原始标题，可以是中英文混合") },
  async ({ title }) => {
    const slug = title
      .toLowerCase()
      .replace(/[^\p{L}\p{N}]+/gu, "-")
      .replace(/^-+|-+$/g, "");
    return { content: [{ type: "text", text: slug }] };
  }
);

await server.connect(new StdioServerTransport());

三条经验。其一，工具说明是写给模型看的，要说清「什么时候该用、参数是什么」，写含糊了模型就调不准。其二，参数必须用 schema 校验并返回友好的错误信息，别让异常把 Server 进程打崩。其三，先单独调试再接客户端：协议方提供了 Inspector 这类调试工具，不启动 AI 应用就能逐个验证工具的输入输出。字段与 API 形态以 SDK 当前版本的官方文档为准。

七、排错：按现象定位

改完配置毫无反应。 最常见的原因是客户端没有完全退出，后台进程还驻留，配置根本没被重新读取，先从托盘或菜单里彻底退出再打开。其次是改错了文件：同一应用可能有多个配置位置（有的分用户级和项目级），对照文档确认你改的是生效的那份。
Server 启动失败。 把配置里的 command 加 args 原样粘到终端里手动运行，报错会直接告诉你卡在哪。常见情形依次是：运行时没装或版本不够、桌面应用找不到 npx 等命令（改用完整路径）、包名拼错、首次运行要下载依赖被误判成卡死——最后这种多等一会儿就好。
配置解析报错。 基本都是 JSON 语法问题：多了尾逗号、引号不配对、Windows 路径里单个反斜杠没有转义。存盘前用 JSON 校验工具过一遍，省掉来回重启的折腾。
连上了但工具不出现。 连接成功只代表进程活着，不代表工具注册成功。先在客户端界面里确认该 Server 的状态与工具列表，再手动跑一遍看启动日志；多数客户端会为每个 Server 留日志文件，位置查各自文档，里面通常有现成的失败原因。
工具出现，但一调用就报错。 分三层查：权限层，目标目录或账号根本没被授权；凭据层，Token 过期、权限不足或被吊销；网络层，远程 Server 或目标 API 连不上、超时。前两层占了绝大多数。
AI 压根不主动调用工具。 先把需求说具体，比如点名「用文件工具列出这个目录」，而不是含糊地问「看看这个项目」。装的 Server 太多、工具太杂，模型同样会挑花眼，先禁用不相关的几个再试。还有个变量是模型本身的工具调用稳定性，弱模型多步任务容易中途放弃，换个任务或模型验证一轮就能确认。
越用越慢、内存涨。 每个 Server 都是常驻进程，装得多，启动开销与内存占用自然水涨船高。按场景备几套配置、用到哪套开哪套，比全部常开更稳。浏览器类 Server 还要留意没关掉的标签页，那是内存大头。

写在最后

给三类人各一条起步建议。只想让 AI 碰到自己文件的人，装一个文件系统 Server、白名单只给一个项目目录，安全清单过一遍，今天就能用上。写代码的人，在编辑器里接上文件系统和 GitHub，Token 从只读开始，配合顺了再逐步放开写权限。愿意折腾的人再往数据库和浏览器走，但每多接一个 Server，就多问一遍它能碰到什么——MCP 的价值不在装得多，而在于 AI 能稳定、安全地替你完成真实动作。想把 AI 工具链系统补齐的，可以接着看 AI Agent 终极指南、AI Coding 工具指南和 DeepSeek 本地部署教程，而 Claude AI 完整使用指南适合先把客户端本身用熟。

延伸阅读

免责声明

本文仅供技术交流和学习参考。涉及第三方服务的链接可能包含 sponsored 标记，请自行核实服务条款、价格和可用性，并遵守当地法律法规。

MCP 协议入门与实战指南 2026：让 AI 连接万物 ​

一、先分清：MCP、函数调用、插件不是一回事 ​

二、接入前检查清单 ​

三、接入第一个 Server：以文件系统为例 ​

四、常用 Server 按场景分组 ​

文件与本地数据 ​

代码协作 ​

数据库 ​

浏览器与网页 ​

搜索 ​

五、安全边界：权限、凭据与提示注入 ​

最小权限：让每个 Server 只碰它该碰的 ​

凭据隔离：别让一把钥匙开所有的锁 ​

来源可信：你装的是一段要长期运行的代码 ​

提示注入：内容是数据，不是命令 ​

六、两个进阶方向 ​

让本地模型也能调用 MCP ​

自己写一个 Server ​

七、排错：按现象定位 ​

写在最后 ​

延伸阅读 ​

延伸阅读 ​

MCP 协议入门与实战指南 2026：让 AI 连接万物

一、先分清：MCP、函数调用、插件不是一回事

二、接入前检查清单

三、接入第一个 Server：以文件系统为例

四、常用 Server 按场景分组

文件与本地数据

代码协作

数据库

浏览器与网页

搜索

五、安全边界：权限、凭据与提示注入

最小权限：让每个 Server 只碰它该碰的

凭据隔离：别让一把钥匙开所有的锁

来源可信：你装的是一段要长期运行的代码

提示注入：内容是数据，不是命令

六、两个进阶方向

让本地模型也能调用 MCP

自己写一个 Server

七、排错：按现象定位

写在最后

延伸阅读

延伸阅读