你可能已经习惯让 AI 写文案、改代码、查资料，但它始终和你隔着一层玻璃：看不见你本地的文件，连不上你的数据库，也没法替你把一句话发出去。MCP（Model Context Protocol，模型上下文协议）就是来拆掉这层玻璃的——它给 AI 应用定了一套统一的「外挂接口」标准，让客户端能按同样的规矩接上外部工具和数据。这篇用零基础的讲法把 MCP 讲清楚，看完你能判断自己到底需不需要它。
一句话理解 MCP：AI 世界的 USB-C
在 MCP 出现之前，每接一个新工具都是「一对一」写适配：A 客户端要连数据库，写一套；B 客户端也要连同一个数据库，再写一套。客户端越多、工具越多，工作量是乘法级往上翻的。
MCP 做的事，就像 USB-C 统一了充电口：工具方只要按 MCP 协议做成一个 MCP Server，所有支持 MCP 的客户端都能直接插上就用。原本「客户端数 × 工具数」的乘法题，一下就变成了加法题。
三个角色：Host、Client、Server
一条 MCP 连接里只有三个角色，记住它们基本就懂一半了：
- Host（宿主）：你实际在用的那个 AI 应用，比如 Cherry Studio、Chatbox 或某些 IDE 插件。界面、权限、要不要批准这次调用，都由它负责。
- Client（客户端）：宿主内部的一个「插槽」，与某个 Server 保持一对一连接，按协议收发消息。它一般由应用自己实现，你基本不用管。
- Server（服务端）：真正干活的那个小服务，比如「读写本地文件」「查数据库」「操作某个网站」。一个 Server 通常只专注一件事。
而 Server 是通过三种能力把自己的本领交给 AI 的：
- Tools（工具）：可以让模型主动调用的动作，比如「读取这个文件」「发起一次搜索」。这是日常用得最多的一类。
- Resources（资源）：只读的数据，比如某个文件的内容、某张表的只读视图，更像「给 AI 递资料」而不是「让 AI 动手」。
- Prompts（提示词模板）：预先写好的指令模板，一键调用，省得每次手打一长串要求。
小提示：本地运行的 Server 一般走 stdio 传输（宿主把它当子进程拉起来），远程的走 HTTP 类传输。这个细节属于实现层面，配好能连上就行，不用深究。
怎么用起来？两步就够了
第一步，装一个支持 MCP 的客户端；第二步，在客户端的 MCP 设置里填一段配置。整件事的门槛其实就卡在这段配置上。
配置的套路很固定：在 mcpServers 里给每个 Server 取个名字（比如 filesystem），然后写清它是怎么启动的——本地 Server 填一条启动命令，例如 npx -y @modelcontextprotocol/server-filesystem D:/docs，表示「把 D 盘 docs 目录开放给 AI」；远程 Server 则填一个 URL 再配鉴权。保存后客户端会把它拉起来，AI 就多出了几个能调用的工具。
要注意的是，MCP 管的是「AI 怎么连工具」，不负责「AI 用哪个模型」。模型那一环仍然需要 API Key——把接口地址填成 https://api.aigcbreeze.cn/v1，模型填 deepseek-v4-flash 或 glm-5.3，一个 Key 就能在客户端里换着用。
常见问题
MCP 和 Function Calling 有什么区别？
Function Calling 是模型层面的能力：模型看到工具清单后，输出「我要调用某个函数、参数是什么」。MCP 是工程层面的协议：工具由谁提供、怎么被发现、怎么连接、怎么鉴权，全由它规定。两者不冲突——MCP 里的 Tools 最终还是靠 Function Calling 让模型决定要不要动手。
用了 MCP，还需要 API Key 吗？
需要。MCP 解决的是「连什么工具」，模型本身还是得有一个能调用的接口。所以配置里通常有两块：MCP Server 列表，以及模型服务商的接口地址和 Key。
MCP Server 装多了会怎样？
两个问题。一是占上下文：每个工具的名称和说明都会塞进提示里，装太多会挤占原本留给正文的空间；二是安全面变大：能读文件、能发请求的 Server 相当于把一部分权限交出去了，只装来源可信的，能不给写权限就不给。