没有 MCP 之前，接工具有多麻烦
在MCP出现之前,每接一个新工具都要单独写集成代码、处理认证、适配格式 ,而且这套代码和具体模型强绑定 ,换个模型就得重写,非常繁琐。
MCP的思路是把这件事标准化 :工具提供方按协议实现一个Server,任何支持MCP的Al客户端就能直接接进来,一次实现到处复用。
MCP的核心思路
MCP的设计思路做的是一件事:
为「Al接工具」这件事定了一套统一的协议标准。工具提供方(比如GitHub官方)按MCP规范实现一个MCPServer,里面封装好各种操作。 任何支持MCP的Al客户端,Claude Desktop、Cursor、各种Agent框架,都能 直接连上这个Server ,自动发现里面的工具并使用,不需要写任何定制化对接代码。
MCP的Client-Server架构
MCP采用标准的Client-Server架构。
Server是工具的实现方 。比如GitHub官方维护一个GitHHub MCP Server,里面封装了「列出PR」「创建Issue」「搜索仓库」「查看Diff」等操作;Client是Al应用那一侧,比如Claude Desktop或Cursor,连上Server之后就自动获得了这些工具能力。
一个Client可以同时连接多个Server 。把文件系统Server+GiitHub Server + PostgreSQL Server 都接上,模型就同时拥有了操作本地文件、读写代码仓库、查询数据库这三套工具能力,
而你不需要写任何对接代码,只需要在配置文件里加几行JSON,重启后Claude自动发现并使用这些工具。
MCP的三类核心能力
先说Tools(工具)
这是最核心的能力,对应Function Calling里的「函数」 。
Tools的本质是「有副作用的操作」 ,什么叫有副作用?就是执行之后会改变外部世界的状态。创建文件、提交代码、发送Slack消息、调用第三方API,这些都属于Tools,因为执行完之后环境发生了变化,而且往往不可逆。
正因为如此,Tools通常需要用户授权确认才能执行,不能让模型想调就调。
再说Resources(资源)
它和Tools最本质的区别 就一个字:只「读」 。Resources不会改变任何东西,只是把数据提供给模型看 。读取日志文件、查询数据库记录、获取文档内容,都属于Resources的范畴。
你可以把Resources理解成「工具的资料室」,模型可以进去查资料,但不能修改里面的东西。
正因为只读、无副作用,Resources可以更宽松地暴露给模型,不需要像Tools那样谨慎授权。
最后是Prompts(提示模板)
这个能力很多人容易忽略,但在团队协作场景下特别有用。Prompts就是预定义的提示词模板,带参数占位符 ,解决的是「每次都要手写重复prompt」的问题。
举个例子,你的团队有一套固定的代码审查标准 prompt,接受「编程语言」和「代码内容」两个参数,调用时只需传入参数值,就能自动展开成完整的提示词,不用每次从头写。
把公司积累的优质 prompt封装成MCP Prompts,所有人都能复用,统一标准,这在实际工程中很实用。