大家好，我是韩数同学。致力于分享 Github 上那些 好玩 有趣 免费 实用 的高质量项目。
我们关注这个世界上那些新奇的开源项目，作为开源技术博主，我们也很想带你去了解那些技术背后的事情, 今天是我们 AIGC 首篇文章, 关于 MCP 协议。
为什么我们需要 MCP
在了解什么是 MCP 之前, 我们需要先最基础的了解下大模型，也就是我们通常所提的 LLM. LLM 的概念到今天已经完全不再陌生, 首先大语言模型主要的特点则在于它使用过去的数据训练而成, 因此未开启联网能力下的大语言模型的知识则停留在训练他的数据那一刻，我们可以写一个例子简单证明这一点:
例如我们可以问大模型一个简单的问题: 请帮我生成一个 json 数据，使用最新的日期
因此这就意味着一个明显的问题，那就是大语言模型的局限性，试想人类如何获取新知识？
我们可以上搜索引擎查网页, 去图书馆查阅相关数据，还可以缠着朋友问，我们依靠主动与世界交互而获取新知识，而单纯靠大模型本身很难做到这一点。
知识的局限性和缺乏和与用户电脑进行真实交互极大的制约了大语言模型的能力。
Function Calling 和 Tool
而为了解决这个问题，各个大模型服务商提出了 Function Calling 和 Tool 概念， Function Calling 为 OpenAI 模型提供了一种强大且灵活的方式，使其能够与外部系统进行交互，并访问其训练数据之外的数据。Tool 则是由 OpenAI 已经内置托管的一系列 Function Calling, 例如联网搜索，生成图像，解析文件等等等。
例如当我们需要问大模型当前的天气如何时，我们需要定义这样一个 Function Calling 并注册到 大模型 的上下文中。
此时的 Function Calling 注意它的 parameters 部分已经和 MCP 的协议非常像了，这部分基本上是从 Openapi 的协议演变而来的。
调用过程：
Function Calling 执行流程:
- Code：将function描述和要求发送给LLM
- LLM：LLM来确定是直接给答复，还是需要调用 function
- LLM：如何要调用function，则返回需要调用的 function 以及调用 function 所需要的参数
- Code：程序收到 LLM 返回后，根据 LLM 的返回信息，执行 function
- Code：将 function 执行后得到的结果，以及 prompt 提示词发送给 LLM
- LLM：LLM 产生最终回答
当我们只需要解决类似于查天气这类比较特定的场景时，使用 Function Calling 是非常合适的，但是当我们需要大量 Function Calling 时，意味着我们则需要为每一个功能项都实现对应的调用函数, 比较麻烦，第二个不同的大模型的 Function Calling 的协议可能还不一样。因此我们需要一种协议，可以将各种数据源或者操作以服务的方式使用统一的协议从外部集成到大模型的工具中供大模型调用，从而增强大模型的能力，为大模型安装能与聊天框之外进行实际交互的触手
MCP 协议
在这样的一个背景下, 2024 年 11 月 25 日, Anthropic 发布了一篇文章, 正式提出了 Model Context Protocol 模型上下文协议, 也就是我们所熟知的 MCP, 并同步推出了相关的 SDK 套件, Claude 客户端针对 MCP 的支持, MCP 相关的开源仓库。发布即可用，站在今天的角度回看这篇不到千字的博客，很难不认为这是一次蓄谋已久的针对 OpenAPI 的突然袭击。
在这篇文章中, Anthropic 提出了关于 MCP 的最初构想, MCP 解决了 Function Calling 引发的扩展困难，协议混乱这一挑战。它提供了一个通用的开放标准，就像电脑是 IO 接口与 USB 标准一样。用于连接 AI 系统与数据源，用单一协议替代分散的集成。结果是为AI系统提供所需数据访问的更简单、更可靠的方式。
有了 MCP 之后，大模型可以以统一的方式读懂来自四面八方的数据操作了。
2025 年，随着越来越多的公司和开发者针对 MCP 协议达成共识，MCP 成为了大模型与第三方数据源集成的事实标准。
就像上面那张图所示的，在 MCP 出现之前，大模型是一个没有四肢只有嘴巴的人类，所有的一切知识需要人工整理好之后一点点喂进去嘴巴里面。想象一下，在 MCP 出现之前，我们想让大模型帮我们做一些需要外部数据源的事情时，例如分析公司最近一个月的营收信息 这样的需求时，我们要如何做？自己从公司的数据库中拉取信息，整理成对 llm 友好的格式例如 csv 或者 json。然后把数据粘贴进大模型冰冷的聊天框，搭配自己精心准备的 prompt，然后交给大模型去分析。这和嚼碎了喂饭没有本质上的区别，这时候当另外一个人也有类似的需求的时候时，你会发现他也需要这么从头来一遍。而 MCP 的出现则很好的解决了这个问题:
- 协议的一致性可以保证不管是 deepseek和 claude 调用 mcp 时可以保证一致的行为。
- MCP 的能力可以共享了，平台方例如 jira 或者 slack 可以封装成 MCP 插件，所有需要调用 jira 或者 slack 的人无需二次开发，可以实现开箱即用。
- 数据安全，如果你需要大模型读取内部数据，你可以实现自己的 MCP server 并决定返回哪些数据。
MCP 协议组成部分
MCP 主要有以下三部分组成，分别是客户端(Client), 主机(Host) 和 服务器(Server). 这里的主机可以理解为发起请求的 LLM 程序，比如 大模型桌面端。每个 host 可以运行多个连接(client)。每个 client 都可以连多个 MCP 服务，client 使用 Rpc 的方式与服务端通信。例如deepseek 可以同时安装 slack 和 jira, github 等多个 MCP server。
MCP Client 与 Server 保持一对一的连接, 当我们向大模型提问时:
- MCP Client 会先从 Mcp server 获取所有可用的 MCP Server 提供的 tool 列表, 然后一并交给大模型。
- 大模型会根据上下文决定是否使用工具， 如果需要执行工具，则会生成对应的调用询问用户是否执行该 tool,用户确认过之后（询问这部不同的客户端的行为可能不一样), MCP Client 带着参数执行对应 tool 所属的 Mcp Server 的调用。
- MCP Client 将 MCP server 调用的返回结果发送回 llm.
- LLM 基于上下文以及 MCP Server 调用的结果生成回复。
除了 MCP client，另外一个核心的组件就是 MCP server 了。MCP server 可以是远程服务器，也可以是本地在 docker 中运行的服务，但是他们提供的作用都是一样的，以 api 的方式提供能够实际执行的操作。MCP server 主要有三部分构成
- 资源: 可以是文档或者 api 返回信息等。
- 工具: 实际可以执行的操作，例如调用查询数据。
- 提示, 预先编写的 prompt，比如你提供一个生成 ppt 的 mcp prompt
MCP 的出现确实弥补了传统的 function calling 的不足，但是现阶段的 MCP 并不能算是完美的，仍然还有许多问题需要解决。1. #### token 的消耗问题，这应该是最轻的一个问题了，当我们向 llm 提问时，llm 始终会去加载所有的 mcp tool 去判断是否调用 mcp 工具。如果我们注册了过多的 mcp server，则会加剧 token 的消耗。同时如果多个 mcp server 存在功能相似 tool, 这些 tool 的描述写的也大差不差，这个时候 agent 判断调用哪个 mcp server 的 tool 的准确性就会受到很大的影响。
- 安全风险, 如果一个非法的 mcp server 提供了 某些和 jira 类似的 tool, 就有可能造成 mcp 名称冲突攻击，即将一些可能包含敏感信息的参数发送给相似的确实错误的 mcp server 上。同时由于目前 mcp server 缺乏统一的认证体系，因此从一些第三方网站安装的 mcp server 可能存在恶意程序。等等等等
- 缺乏统一的认证体系和细粒度的权限控制。不同的 mcp server 的认证方式可能完全不同, 有的使用环境变量注入 api_key 有的使用 oatuh 等等。
- 基于 jsonrcp 的协议无法处理文件上传这种复杂的操作。
- 潜在的性能问题, 由于 mcp 连接远程 MCP 只支持 SSE 协议, 但是由于 SSE 是一个长链接服务，因此对于高性能高并发的场景并不是十分友好
总结
关于 MCP Server 的开发，如果你之前已经接触过后端开发，那么开发一个 MCP Server 对于来说并不是一项难事, 无非是提供另外一种样式的接口罢了 MCP 并不是技术上非常高大上的东西，但确实是人工智能时代发展过程中的必然产物。现阶段的 MCP 协议仍然称不上完美, 仍然有许多需要完善的地方, 但是无法否认的是，MCP 的出现确实为 AI 增加了四肢, 将我们带向了更远的地方，使得更多的事情变得可能。
介绍下我自己
我是韩数同学，技术博主&开源博主，如果你想要知道这个世界上有哪些 好玩,有趣,免费,实用 的开源项目，欢迎在绿泡泡或者红泡泡搜索我们。