一文看懂MCP：是什么、能做什么、怎么用（2026年更新）
更新时间：2026年7月16日
MCP让AI应用用相对统一的方式连接外部工具和数据
刚开始接触MCP时，人们最容易犯的错，是把它当成某个新模型或者某种“让AI突然变聪明”的插件。其实它更像一套接口标准：模型仍然负责理解和推理，MCP负责告诉AI应用，外面有哪些东西可以连接、怎样连接、能做什么。
如果把AI比作刚搬进新家的住户，模型能力就是它会不会做饭、会不会整理房间；MCP则更像统一的插座和水管接口。有了接口，台灯、冰箱和洗衣机不需要每次都重新改造墙体。但插上什么设备、给多少权限、设备本身是否安全，仍然要由人来判断。
MCP解决的，到底是什么问题
模型原本只知道训练时学到的内容，以及你当前发给它的文字。想让它查询公司的最新文档、读取本地项目、调用数据库或创建工单，应用开发者通常要为每个系统单独写一套连接代码。
连接一个系统不难，难的是系统越来越多：同一个网盘要分别适配聊天助手、代码编辑器和桌面客户端；同一个AI应用又要分别适配网盘、Git仓库、工单系统和数据库。最后，大家把大量时间花在重复接线，而不是把数据真正用好。
Model Context Protocol，简称MCP，尝试给这些连接提供一套开放协议。支持MCP的应用可以用相似的方式发现服务器提供的能力、读取上下文并发起调用。它不消灭所有适配工作，但把“每两套系统都私下约定一次”变成了“尽量围绕同一套协议对接”。
三个角色：谁在跟谁说话
MCP架构里经常出现Host、Client和Server三个词。名字看起来像网络课，其实关系并不复杂。
Host（宿主应用）：用户真正打开的AI应用，例如桌面助手、IDE或智能工作台。它负责对话、权限提示和整体体验。
Client（客户端）：宿主应用内部负责建立MCP连接的一方。一个宿主可以同时连接多个服务器，并分别管理会话。
Server（服务器）：向客户端提供数据或操作能力的一方。它可以在本机运行，也可以部署在远端。
举个日常例子：你在IDE里说“找到昨天会议提到的接口变更，再检查代码是否已经同步”。IDE是宿主；它内部的MCP客户端分别连接文档服务和代码仓库服务；两个服务器提供搜索文档、读取文件或查询提交记录的能力。模型负责决定先查什么、怎样综合，真正的数据访问由对应服务器完成。
服务器通常会提供三类东西
Tools（工具）是可以执行的动作，例如搜索工单、运行查询、创建日程。它们往往会产生外部影响，因此调用前尤其需要权限控制和参数确认。
Resources（资源）是可以读取的上下文，例如文件、数据库记录、知识库页面。它更像把资料递给模型，而不是让模型按下一个会改变现实世界的按钮。
Prompts（提示模板）是服务器预先定义的可复用交互方式，帮助客户端用合适的结构发起某类任务。
一些客户端还可以向服务器提供采样、信息征询和日志等能力，协议也在继续增加新的机制。对普通使用者来说，不必一开始记住全部名词。先分清“读资料”和“做动作”，已经能避开很多权限误判。
MCP和函数调用不是一回事
函数调用通常描述模型如何从一组函数定义里选择一个，并生成结构化参数；MCP关注的是应用与外部能力如何建立连接、发现能力和交换上下文。两者可以一起工作，却不在同一层。
仍以家用电器来比喻：函数调用像住户决定“现在启动洗衣机，并选择快洗30分钟”；MCP更像洗衣机如何接入房屋、怎样声明自己有快洗模式，以及控制指令按什么格式传过去。只有决定，没有连接，机器不会动；只有连接，没有决定，也不知道该什么时候动。
本地连接和远程连接
本地MCP服务器常通过stdio与客户端通信。客户端启动一个本地进程，通过标准输入输出交换消息。这类方式适合读取本机文件、访问开发工具，部署简单，但服务器进程能接触哪些本地资源，取决于它获得的系统权限。
远程服务器当前主要使用Streamable HTTP。它适合跨机器、跨团队的服务，并能结合认证和集中运维。早期文章常把HTTP加SSE写成唯一远程方案，这已经不是完整的现行描述；阅读旧教程时要留意协议版本。
底层消息采用JSON-RPC等约定。大多数使用者不必手写消息，但理解这一点有帮助：MCP不是把整个桌面“神秘地交给AI”，而是通过有名称、有参数、有返回值的请求来工作。
实际使用时，配置只是开始
不同客户端的配置文件位置并不相同，但一个本地服务器配置通常会包含服务器名称、启动命令和参数，结构大致类似：
{
"mcpServers": {
"example": {
"command": "your-server-command",
"args": []
}
}
}这段示例只说明结构，不对应某个可直接安装的服务器。复制网上的配置前，至少先弄清楚命令会安装或运行什么、代码来自哪里、需要哪些环境变量，以及它能访问哪些目录和账号。
比较稳妥的顺序是：
从明确的问题出发，例如“需要让IDE只读查询项目工单”，而不是先装几十个服务器再找用途。
在官方Registry、项目官方仓库或可信发布渠道核对服务器身份、维护状态和版本。
使用最小权限账号和最小目录范围，能只读就先不要给写入权限。
先在测试数据上验证工具名称、参数和结果，再允许它接触真实业务。
定期检查更新、撤销不再使用的令牌，并删除闲置配置。
“能在Registry里找到”不等于绝对安全
MCP生态已经从早期的一长串示例仓库，发展到使用Registry进行发现。官方servers仓库现在主要保留少量参考实现，并明确提醒这些实现更偏演示和教学，并不天然适合生产环境。
Registry解决的是“在哪里发现和识别服务器”，不是替用户完成全部安全审计。一个服务器即使能被检索到，也仍可能请求过大的权限、依赖外部服务、保存敏感数据，或者在后续版本里改变行为。
尤其要警惕三件事：第一，把访问令牌直接写进可分享的配置；第二，允许未知服务器读取整个用户目录；第三，让具有写入、删除或转账能力的工具在没有确认的情况下执行。协议统一了接线方法，却不会自动替每台电器装上保险。
MCP最适合哪些场景
它适合那些需要在多个AI客户端之间复用连接能力，或者需要把内部数据以清晰边界提供给AI的场景。开发者可以让编程助手查询代码和工单，运营人员可以让工作台读取知识库，企业也可以把内部系统封装成权限可控的服务。
但如果一个应用只调用一个固定接口，而且不会被其他客户端复用，直接写普通API集成可能更简单。MCP是一种标准化选择，不是所有功能都必须套上的外壳。
想继续看具体实践，可以阅读AI全书的Cursor中配置MCP Server和MCP如何影响AI编程。配置项会随客户端版本变化，操作时仍应以对应产品的当前文档为准。
归根结底，MCP的重要性不在于又多了一个缩写，而在于AI开始从“只会回答”走向“能连接资料和工具”。连接越方便，权限边界就越值得认真对待。真正成熟的用法，不是把所有东西都接进来，而是让每一次连接都有明确用途、可信来源和可撤销的权限。
声明：本文用于介绍MCP概念和一般实践，不为任何第三方服务器作安全背书。安装或授权前，请独立核验代码来源、权限、数据处理方式和维护状态。