mcp 是什么？论工具的自我修养

先说结论：MCP 是类似 RESTful API 的一种约定，用于统一 AI 和工具之间的输入输出格式，它不是新东西，只是它以前没有名字。

在 MCP 出现之前，大语言模型已经有“工具调用”的能力，这是通过在模型训练时引入了特定格式的文本数据实现的，例如，通过大量的 json 格式文本，教会了模型如何解析和生成 json 数据。

通过告诉模型，这里有一些 API，它们都是你可以使用的工具，你可以把想要使用的工具的名称和参数通过 json 的方式输出，外面有一个执行系统就会按你的要求进行执行，然后再把执行结果用 json 的格式返回给你。

举个例子，比如，这里有个名叫“查询天气”的工具，其参数是一个城市名，例如“北京”，表示查询北京的天气情况。

大模型知道了这一点，当用户问他今天上海的天气怎么样的时候，大模型就可以构建一个这样的 json 文本作为查询参数：

{
	"tool": "查询天气",
	"params": {
		"city": "上海"
	}
}

我们提到“模型”的时候，其实指的是个很笼统的东西，它可以仅仅指大模型的权重，也可以指驱使模型运行的环境。如果把模型权重比喻为人的大脑，那模型运行环境就是人的身体，让模型可以与外界交互。

以 ollama 举例，ollama 就是一个可以让模型运行起来的环境，我们想用 ollama 运行 qwen2.5(千问 2.5)，就需要先下载 qwen2.5 的权重文件，相当于得到了 qwen2.5 的脑子，然后 ollama 会给这个脑子插上管子、输送营养液、检测它的脑电波信号，让它活过来，可以与我们对话。

qwen2.5 具有调用工具的能力，因为它“出厂”前接受过这样的训练，它会表达，它的脑电波告诉 ollama：“接下来我要调用工具了，参数是这些，你吩咐外面的人去执行，执行好了把结果告诉我”。它是一个发号施令的人，执行的人不是它，因此这叫“工具调用”，而不是“工具执行”。

ollama 也不是执行工具的人，它是一个医生，确保 qwen2.5 可以活着跟外面交流。

真正执行工具的人是门外的一群小弟，他们会先自报家门，告诉 qwen2.5：“问哥，我叫小查，可以查询天气，我以千问大佬您马首是瞻，只要一声令下，就算上刀山下油锅，我都会查到您需要的天气。”

理想情况下，小弟们都像小查一样态度积极、勤奋工作。但是，小弟多了，总会有几个异类，有的小弟沉默寡言，态度高冷。qwen2.5 问它：“你是谁？你能做什么？”小弟嗤笑一声，不予理会。这样的小弟，就会很让人头疼。

这时候 MCP 就发挥作用了，MCP 全称模型上下文协议，可以将它认为是一本书，其中有这样几个章节：“工具”、“资源”、“提示词”、“通信”，现阶段，我们只需要关心工具和通信两个章节。

工具这个章节，又名《工具的自我修养》，里面写道：一个合格的工具，必须要学会自我介绍，必须提供清晰、描述性的名称和说明，提供详细的参数说明，在工具描述中包含示例，实施适当的错误处理和验证，对长时间操作进行进度报告，考虑对资源密集型操作进行速率限制等等。

一个合格的工具，还要学会保护自己，在需要时实施身份验证，使用适当的授权检查，审计工具使用情况，进行日志记录，监控滥用行为。要验证所有参数，检查参数大小和范围，防止命令注入。要进行错误处理，不要向客户暴露内部错误，记录与安全相关的错误，适当处理超时，错误发生后清理资源，验证返回值。

一个合格的工具，还要有成长性思维，要经常升级版本，提高自身技能，修复自身 bug。在更新版本后，要及时向模型报告。

模型作为雇主，有权随时添加和删除工具，工具必须及时响应，不得有任何怨言。

而通信这个章节，又名《所有工具都必须说普通话》，里面写道：所有工具必须口齿清晰伶俐，说普通话，不得使用方言，必须使用 JSON-RPC 2.0 格式与雇主交流，不得使用 yaml、toml 等格式。

与雇主交流时，可以使用面对面交谈 (stdio 控制台标准输入输出)，或者打电话交谈 (SSE 服务器发送事件)，或者与雇主协商交谈方式，例如线上会议。

有了 MCP 后，qwen2.5 就省心多了，哪个工具不听话，就让它抄《工具的自我修养》800 遍，实在不合格的工具，直接清除工籍，永不录用。

而且不止 qwen2.5，其他模型也将 MCP 视为瑰宝，用它来约束工具的行为，久而久之，MCP 就会成为行业标准。

而且工具本身也受益于 MCP，当所有雇主都将 MCP 视为标准，那么只要工具遵守 MCP 协议的规定，那么它就能在所有雇主那里找到工作。

好的，现在大家已经知道了 MCP 是什么，那么，可能还有一个大家比较关心的问题，MCP 似乎逐渐火热，例如 cline / zed / cursor / windsurf 甚至 jetbrains 家的 ide 都开始支持 MCP 了，vscode 也正在调研内置 MCP 支持，那么，这么一个新鲜市场，我们可以靠 MCP 赚钱吗？

答案是肯定的，新鲜市场绝对有赚钱的机会！但是，你无法仅通过 MCP 来赚钱，MCP 只是一套规范，想要赚钱，你需要有好的业务、做出好的工具、实现好的用户体验。

MCP 更像是给大模型特供的 API，未来一定会成为大模型的标配。

那么，做一个全新的 MCP 工具难吗？或者为现有的工具添加 MCP 支持难吗？

不难，绝对不难，学习制作 MCP 工具不会比学习一个新的 http 框架更难，甚至可以说完全一样，如果你是一名后端或全栈开发者，有过接口开发经验，那你就爽了，因为你可以仅仅通过阅读文档和看两个示例就能学会 MCP 工具开发，不会有任何门槛。

如果你没有相关经验，那也完全不成问题，deepseek 或 claude 等模型具有强大的编码能力，给它们看一看文档，它们就能帮你轻松踏上开发 MCP 工具的旅程。

希望这篇文章对你有所帮助，如果你觉得写得不错，希望你可以点个关注，我还会分享更多有用的知识和技术思考，期待与你共同成长。