跳至主要內容

Tool Use 生态的现状——MCP 会成为标准吗

老张2026/4/30大约 7 分钟

Tool Use 生态的现状——MCP 会成为标准吗

适读人群：关注 AI 工具生态的工程师和产品人 | 阅读时长：约14分钟 | 核心价值：MCP vs 其他方案的真实对比，帮你判断是否要押注 MCP

三个月前，一个群友在群里说"MCP 要统一 AI 工具调用了，赶紧跟上"。我当时的第一反应是：又来一个"要统一天下"的协议。

做工程的人见过太多这类故事了。XML 要统一数据交换，SOAP 要统一服务调用，GraphQL 要统一 API 设计……每隔几年就有一个新的"标准"出来说要统一所有人。

但 MCP 这个东西我认真研究了，它跟之前那些有点不一样。不是说它一定会赢，而是它切入的时机和切入的角度都比较准。

MCP 是什么，用一段话说清楚

MCP（Model Context Protocol）是 Anthropic 2024 年底提出的开放协议，定义了 AI 模型如何与外部工具、数据源、服务交互的标准接口。

简单说：它想做的事是，让任何工具只需要写一次 MCP 接入，就能被任何支持 MCP 的 AI 模型使用——类似于 USB 标准解决了设备接口问题。

协议本身分三层：

Client（AI 应用/IDE）
    |
    | MCP 协议（JSON-RPC over stdio/HTTP SSE）
    |
Server（工具提供方）
    |
    +--- Resources（数据读取，如文件、数据库）
    +--- Tools（操作执行，如搜索、发邮件）
    +--- Prompts（模板，如预设的工作流）

这个架构的关键是把"工具定义"和"工具实现"分开了。AI 模型不需要知道工具怎么实现，只需要知道工具的接口描述；工具提供方不需要针对每个 AI 模型单独适配。

已接入 MCP 的工具生态

截至目前（2025 年 4 月），我整理了一下比较有代表性的 MCP Server 实现：

开发工具类：

  • Claude Desktop（官方客户端，直接支持）
  • Cursor、Continue 等 AI IDE 插件
  • GitHub（官方提供 MCP Server，可以读 repo、issue、PR）
  • Postgres、SQLite（数据库查询）
  • Filesystem（本地文件读写）

SaaS 工具类：

  • Slack（发消息、读频道历史）
  • Google Drive / Google Maps
  • Brave Search（搜索）
  • Notion（读写页面）
  • Puppeteer（浏览器自动化）

数据和分析类：

  • AWS Knowledge Base
  • Qdrant、Chroma 等向量数据库
  • Prometheus（指标查询）

这个列表每隔几周就在扩充，但我要说实话：目前大多数 MCP Server 是社区贡献的，质量参差不齐。有些只是几十行代码的 demo，生产可用性存疑。真正由工具厂商官方维护的 MCP Server 还不多。

实测体验：在 Claude Desktop 里用 MCP

我把几个 MCP Server 接入 Claude Desktop，说说实际感受。

配置方式（macOS）：

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/laozi/projects"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your_token_here"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
    }
  }
}

实测 1：让 Claude 直接操作本地文件

接入 filesystem server 之后，我让 Claude "读取 /projects/api-server/src 目录下所有 Java 文件，找出没有单元测试覆盖的 Service 类"。

它真的扫描了文件，识别出了几个缺少对应 *Test.java 的 Service，列出来了。这个体验是真的好——以前我要自己写脚本或者手动复制粘贴代码。

实测 2：GitHub 集成

让它"看看 main 分支最近 5 个 PR，告诉我哪个改动风险最大"。它拉了 PR 列表、读了 diff，给了一个分析。准确率一般，但作为"快速过一遍"的辅助工具有价值。

实测 3：数据库查询

这个我测了 Postgres，让它"查询过去 30 天每天的新增用户数，分析趋势"。它生成了 SQL，执行了，返回结果，然后给出分析。

有个问题：它生成的 SQL 有一次写了个全表扫描，加了一个没有索引的 WHERE 条件，差点把测试库搞慢了。生产环境接这种东西要谨慎，建议用只读账号，还要加查询超时。

和其他方案的对比

vs OpenAI Function Calling

OpenAI 的 Function Calling 是最早成熟的方案，使用最广泛。主要区别：

维度MCPOpenAI Function Calling
跨模型通用性目标是通用协议绑定 OpenAI API
工具发现运行时动态发现编译时静态定义
传输层stdio / HTTP SSE只通过 API 请求
状态管理Server 可以维护状态每次无状态
生态成熟度快速成长中目前最成熟

Function Calling 的优势是简单直接——你只需要在 API 请求里定义工具 schema，不需要额外的进程和通信协议。劣势是每个 AI 模型都需要单独适配，Anthropic、Google、OpenAI 的 tool use 格式都不一样。

vs LangChain Tools

LangChain 的 tools 体系是在应用层做集成，工具实现是 Python 类，通过 LangChain 的抽象层调用。

MCP 和 LangChain 的本质区别是：LangChain tools 是库级别的集成，MCP 是进程级别的隔离。

MCP 的进程隔离意味着：工具可以用任意语言实现（不一定是 Python），工具崩溃不会影响主进程，工具可以在远程机器上运行。这对大型系统很重要，但对快速原型来说 LangChain 更简单。

实际上 LangChain 现在也支持把 MCP Server 作为 tools 使用，两者不是非此即彼。

# LangChain 调用 MCP Server 的方式
from langchain_mcp_adapters.tools import load_mcp_tools
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def get_mcp_tools():
    server_params = StdioServerParameters(
        command="npx",
        args=["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
    )
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            tools = await load_mcp_tools(session)
            return tools

我对"MCP 会成为标准吗"这个问题的判断

说几个观察：

支持 MCP 成为标准的因素：

Anthropic 开源了协议规范，不是专有协议，这很重要。开源让竞争对手可以支持它而不觉得是在给 Anthropic 送礼。事实上已经有 OpenAI 内部讨论支持 MCP 的传言（真实性待确认）。

协议设计相对干净。JSON-RPC 是成熟的 RPC 协议，stdio 和 HTTP SSE 覆盖本地和远程两种场景，没有过度设计。

Claude Desktop 和 Cursor 已经有真实用户在用，不是停留在 demo 阶段。

让我存疑的因素：

服务器端实现的复杂性比看起来高。一个生产级的 MCP Server 要处理并发、超时、错误恢复、版本兼容……这些工具厂商不一定有动力投入做。

目前支持 MCP 的 AI 客户端主要是 Claude 系的，其他主流 AI 应用（ChatGPT、Gemini）还没跟进。如果形不成网络效应，协议就会在小圈子里自嗨。

历史上，"统一标准"的项目失败率很高，特别是当标准的提出方（Anthropic）同时也是生态里的竞争者时，其他人接受起来会有顾虑。

我的结论：

MCP 在接下来 1-2 年会继续发展，特别是在开发工具场景（IDE、代码助手）里会有相当大的渗透率。但"统一所有 AI 工具调用"这个目标，我觉得 5 年内很难实现——最终可能是多个协议共存，MCP 成为其中一个重要选项，不会独占市场。

对工程师的建议：如果你在做开发工具或者内部效率工具，MCP 值得学习和接入，投入产出比不错。如果你在做面向 C 端的 AI 产品，暂时不急，等生态更成熟再说。

写一个最简单的 MCP Server

如果你想动手试试，这是一个最简单的 Python MCP Server 骨架：

# my_mcp_server.py
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
import asyncio
import json

app = Server("my-tools")

@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_weather",
            description="获取指定城市的天气",
            inputSchema={
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称"}
                },
                "required": ["city"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_weather":
        city = arguments["city"]
        # 实际项目里这里调用天气 API
        return [TextContent(type="text", text=f"{city}今天晴，气温 25°C")]
    
    raise ValueError(f"Unknown tool: {name}")

async def main():
    async with stdio_server() as (read_stream, write_stream):
        await app.run(read_stream, write_stream, app.create_initialization_options())

if __name__ == "__main__":
    asyncio.run(main())

然后在 Claude Desktop 的配置里加上这个 server，就能用了。整个开发周期不超过半小时，门槛比想象的低。

编辑此页
最近更新:
贡献者: xiaozhangge