MCP协议：Agent工具调用的新标准

工具不是API列表，而是Agent的行动边界

工具描述、参数Schema、返回值、权限边界、错误恢复，这些东西设计不好，Agent一定会乱

但是，如果每个工具都要自己接，那不同工具、不同产品、不同模型之间，岂不是又要重复造轮子

所以，这就是MCP要解决的问题，现在很多Agent项目最大的问题，不是模型不会调用工具，而是工具接入太碎

接Github要写一套，接数据库要写一套，接本地文件要写一套

MCP是一套标准协议，用来让AI应用以统一方式接外部工具、数据和提示模板

注意，它不是模型，也不是Agent框架，更像是Agent时代的"工具接入协议"

为什么会有MCP

假如你要做一个代码助手，让它能完成这些事：

读本地文件
搜Github Issue
查数据库
读公司知识库

如果没有统一协议，每接一个系统，都要自己定义一套工具格式：

工具怎么发现
参数Schema怎么描述
工具怎么调用
工具结果怎么返回
工具权限如何设置

这些问题如果每个产品都自己解决，就会非常混乱

对工具提供方也很痛苦

比如你做了一个数据库查询工具

你想让Claude Destop能用

想让Cusor能用

想让公司Agent能用

难道每个宿主都要写一套插件？

这就太浪费了，MCP的思路是：

工具提供方按MCP标准暴露能力，AI应用按照MCP标准连接这些能力

这样工具和AI应用之间就有了一层统一协议

就像前后端之间用的HTTP API通信

就像数据库客户端通过统一协议链接数据库

它解决的是：AI应用怎么标准化地拿到上下文、调用工具、使用提示模板

MCP不是Function Calling的替代品

这两有关系，但是不是一回事

Function Calling解决的是：

模型这一次响应里面，要不要调用某个函数，以及参数是什么

它更贴近模型调用层

比如你把工具定义发给模型，模型返回：

复制代码

{
	"name":"get_order_detail",
	"arguments":{
	"order_id":"38275923"
	}
}

然后你的程序执行这个函数，把结果再发回模型

这个是Function Calling

MCP解决的是另一个层面：

这些工具从哪里来？怎么发现？怎么连接？怎么通信？怎么暴露给不同的AI应用？

也就是说：Function Calling更像"模型和工具之间的一次调用格式"

MCP更像"AI应用和工具服务器之间的一套连接协议"

可以理解为：

Function Calling关注模型怎么调用工具

MCP关注工具怎么标准化接入AI应用

他们不是排斥关系，很多AI应用会先通过MCP发现工具，再把这些工具转换成模型可以用的Function Calling格式，让模型决定调用哪一个

**Function Calling是模型侧的工具调用机制，重点是模型输出哪个函数和参数，MCP是应用侧的工具接入协议，重点是AI应用如何发现、连接和调用外部工具、资源和提示模板。实际系统里面，MCP可以作为工具来源，Function Calling可以作为模型选择和调用工具的方式

MCP的核心架构：Host、Client、Server

MCP官方架构里面有三个角色：

Host、Clinet、Server

这三个词一定要分清

Host：AI应用本体

Host就是用户真正使用的AI应用

比如：Claude Desktop、Claude Code

Host负责用户交互、模型调用、权限决策、上下文聚合

简单说，Host是"大脑所在的应用壳"

用户不是直接和MCP Server聊聊天，而是在Host里面提问

Client：Host里面负责连接某个Server的组件

MCP Client不是一个独立产品，它通常是Host里面的一段连接组件，一个Host可以连接多个MCP Server

每连接一个Server，Host里面通常就会创建一个对应的Clinet

所以Client的职责是：

和某个MCP Server建立连接
做协议版本和能力协商
发送工具列表请求
接收结果和通知
维护这条连接的安全边界

你可以把它理解成：一个MCP Client对应一个MCP Server的连接通道

Server：提供工具、资源和提示模板

MCP Server是真正提供能力的一方

比如：

文件系统Server：暴露读文件、列目录等能力
Github Server：暴露issue、PR、代码仓库能力
数据库Server：暴露schema、查询工具

Server不负责和用户聊天，只负责按照MCP协议提供能力

这些能力主要有三类：

Tools、Resources、Prompts

这套架构的最大好处是隔离，一个Host可以连接多个Server

但是每个Server不应该直接看到全部对话，也不应该随便访问其他Server的数据

Host负责统一管理权限和上下文，Server只暴露自己该暴露的能力

MCP不是让所有工具都互相打通，是让Host在可控边界内组合多个工具服务器

MCP有两层：数据层和传输层

数据层：定义消息和语义

数据层负责定义：

初始化怎么做
能力怎么协商
工具怎么列出
工具怎么调用

MCP的数据层基于JSON-RPC

比如工具发现可以是tools/list

工具调用可以是toos/call

资源读取可以是resource/read

Prompt获取可以是prompts/get

注意，MCP不是随便使用HTTP路径写几个接口

他有自己的协议方法，请求结构和响应结构

传输层：定义消息怎么传

传输层负责把这些JSON-RPC消息送过去

常见有两种：

stdio

本地进程之间通过标准输入输出通信

这种方式适合本地工具，性能好，不需要网络

Streamable HTTP

通过HTTP和远程Server通信，也可以支持流式能力和标准鉴权

比如远程连接Sentry MCP Server 、公司内部的MCP网关

这种方式适合远程服务、多用户场景、需要认证授权的场景

MCP暴露的三类能力：Tools、Resources、Prompts

这是MCP最重要的一块

MCP Server不只是暴露工具，主要暴露三类能力

Tools：模型可以主动调用的动作

Tools是最像Function Calling的部分

他表示模型可以主动调用的函数

比如：

查询订单
搜索日志
创建工单
修改文件

Tool通常有名称、描述、参数Schema

模型根据用户问题和上下文决定要不要调用它

一句话：Tools解决Agent能做什么动作

Resources：提供上下文的数据源

Resources是给AI应用读取的上下文数据

它更偏向"被动提供信息"

比如：

文件内容
数据库schema
API文档
用户偏好

Resources不一定是模型主动调用的动作

很多时候是Host或者应用根据需要读取，然后放进上下文

Resources解决的是"Agent能看到什么信息"

Prompts:可复用的提示模板

Prompts是预先定义好的交互模块

比如：

帮我规划一次旅行
帮我总结会议

Prompt可以告诉模型应该怎么使用某些工具和资源

prompts解决的是Agent应该按照什么套路做事

一句话总结：Tools是能做什么，Resources是能看到什么，Prompts是怎么做更稳

很多人只把MCP理解成工具调用协议，其实有点窄

MCP真正想标准化的是：AI应用和外部上下文之间的连接方式

MCP一次工具调用大概怎么跑

简单的例子：

"帮我查一下支付服务昨天晚上为什么变慢"

假设Host已经连接了一个监控的MCP Server和一个日志MCP Server

第一步：初始化连接

Host为每个MCP Server创建Client

Client和Server做协议初始化，协商版本和能力

第二步：发现工具

Client向Server发tools/lsit

Server返回自己有哪些工具，比如：

query_api_latency
get_deploy_records

Host把这些工具整理成模型可用的工具列表

第三步：模型决定调用工具

模型看到用户问题后，决定先调用query_api_latency

生成工具名和参数

第四步:Client调用MCP server

Host通过对应Client发出tools/call

MCP Server执行真实查询，返回结构化结果

第五步：模型根据结果继续判断

Agent的规划、判断、反思，仍然由Host里面的模型和应用逻辑负责

MCP为什么适合Agent

Agent最怕什么？不是没有工具，而是工具太多、太散、太不统一

MCP对Agent的价值主要有四个

工具接入标准化

没有MCP，每个AI应用都要自己写工具适配层

有了MCP，工具提供方可以按照标准暴露能力

Host只要支持MCP，就能连接不同Server

这会明显降低接入成本

工具发现动态化

传统Function Calling往往是开发者在代码里面写死工具列表

MCP里面，Client可以向Server发tools/list，动态发现当前Server提供什么工具

如果工具变化，Server还可以通过通知让Client知道

这对大型Agent平台很重要

因为工具不是一成不变的

上下文和动作分开

Tools是动作

Resources是上下文

Prompts是模板

这比所有东西都包装成函数更清楚

比如数据库schema更适合作为Resources

查询SQL才适合作为Tool

多工具组合更自然

一个Host可以连接多个MCP Server

比如：

文件系统Server
Github Server
数据库Server

Host把这些能力聚合之后，模型可以围绕一个任务组合使用

这就是agent需要的能力

但是要注意：MCP让工具接入更标准，不代表Agent自动变可靠

工具描述栏、参数设计栏、权限边界栏，MCP也救不了

MCP只是把"怎么接入"标准化

不是把"怎么设计好工具"自动解决

本地MCP和远程MCP怎么选

MCP Server可以跑在本地，可以跑在远程

本地MCP：适合文件、命令行、开发环境

本地MCP Server常用stdio

Host启动一个本地进程，通过标准输入输出通信

适合：

读本地文件
搜索代码
操作本地Git

优点是快、简单、没有网络开销

缺点是更依赖本地环境，也更需要注意本地权限

远程MCP:适合企业服务和平台能力

远程MCP Server常用Streamable HTTP

适合：

公司知识库
监控平台
工单系统
CRM

优点是集中部署、统一鉴权、方便多人使用

缺点是要处理认证、授权、网络延迟、审计和多租户隔离

所以，对于本地文件、代码和开发工具，适合本地MCP

企业系统、多人共享和需要统一鉴权的能力，适合远程MCP

不要把所有东西都做成本地

要不要把所有东西都做成远程

看数据在哪里、权限怎么管、谁在使用

MCP的安全边界，不能只靠模型自觉

MCP让AI应用更容易连接工具，但是连接越容易，安全问题也就越明显

MCP的安全边界，核心在Host

Host要负责：

连接哪些Server
给每个Server什么权限
工具调用前是否需要用户确认
传给Server哪些上下文
是否允许执行高风险动作
调用记录是否可审计

Server也要克制，不应该默认读取所有上下文

不应该默认访问所有文件，这些都不应该让模型"想调就调"

应该有权限限制、用户确认和审计记录

MCP不是安全魔法，它提供了标准协议和边界设计空间，但是最终安不安全，取决于Host怎么设计权限、Server怎么暴露能力、工具怎么做确认和审计

别把MCP神化

MCP很重要

但是不要把它神化

他不是万能的agent框架，不是用了MCP，Agent就会自动规划、自动排版、自动反思

MCP解决的是连接问题，它让工具、资源、提示模版能以标准方式接入AI应用

但是Agent能不能稳定完成任务，还要看：

工具描述清不清楚
参数Schema严不严
返回值能不能驱动下一步

所以你可以这样理解：

Function Calling是模型调用工具的一种方式

MCP是工具接入AI应用的一套标准协议

Agent是围绕目标持续行动的系统

这三者不是互相替代，而是在不同层面解决不同问题