当前位置：首页 > news >正文

大模型应用实战：深入理解模型上下文协议 MCP

news 2025/4/28 11:11:11

在这里插入图片描述

一、MCP 概述

MCP 是什么？ MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 公司于 2024 年推出的开放协议，用于标准化应用程序向大语言模型提供上下文的方式（将工具语义化，实现动态发现工具、双向传输的客户端/服务器的模块化架构）。

正如 USB-C 提供了一种将计算机连接到各种外设的标准化方式一样，MCP 提供了一种 AI 应用连接到不同的数据源和工具的方式。提供通用适配能力，使大模型或AI应用能够无缝接入数据库、API、本地文件等资源。

本文深入分析了MCP协议的核心特性，并将其与函数调用及A2A协议进行了对比。此外，还提供了具体的开发实例，探讨了在实际应用中可能遇到的问题和挑战。最后，对MCP相关的产业链和生态系统的未来走向进行了预测。

无论你是开发者、技术爱好者还是产业观察者，本文都将为你提供有价值的见解，帮助你更好地理解MCP如何塑造大语言模型交互的未来。

在这里插入图片描述

为什么需要 MCP？ 由于 LLM 难以直接访问实时数据源（如企业内部数据库、实时文档、在线服务等），开发者通常需要为每个应用场景定制专用的适配器或插件，这既耗时费力，又缺乏可扩展性。可以将MCP视为AI领域的"万能适配器"，就像蓝牙技术能够将手机无线连接到耳机、键盘、智能家居等各类设备那样，MCP构建了一个通用协议层，让不同架构的AI模型可以无缝接入数据库、传感器、API接口等多元化资源，实现即插即用的智能化协作。MCP 为智能系统的互联互通奠定基础，不仅降低了AI应用的开发门槛，还为 Agent 生态的未来提供了无限可能。

MCP应用场景 例如，以前使用客户端来查看数据库，启用了数据库MCP，从 IDE AI就可以使用自然语言直接与数据库“对话”，AI编程助手就能更高效地生成更准确的代码，Postgresql 数据库只需实现一个MCP服务器，即可被所有支持MCP的AI客户端（如Claude、Cursor）调用。通过支付宝 MCP服务，基于LLM的智能助手需要付费操作时就可以创建支付链接，确认用户支付后再继续操作。AI智能体可以通过MCP服务器，实现从发送邮件、更新表格，再到创建Jira工单完成复杂工作流。

MCP生态正处于“协议红利期”，中金发布研报称，MCP旨在为大模型及客户端提供标准化接口，使其高效、安全地调用外部数据源、工具，从而突破大模型的静态能力限制，为 Agent 提供技术底座和生态支持。2025年MCP讨论度攀升，核心源于OpenAI、Google等海外头部厂商支持MCP协议，作为MCP Client方入局，当前阿里、腾讯、百度均积极拥抱MCP生态。目前，MCP生态正处于“协议红利期”，早期参与者可以通过定义接口标准、积累AI工具资产以及构建聚合平台形成结构性优势。

二、MCP 发展历程

2024年11月：Anthropic正式发布MCP协议，首次定义模型与外部工具交互的标准化接口。
2024年12月：技术社区涌现首批应用案例，如Claude 3.5通过MCP实现本地文件系统与数据库自动化交互，Cursor发布适配版本验证多工具协作可行性。今年年初，海外平台如Cursor、Windsurf、Cline等率先接入MCP协议
2025年3月：OpenAI、谷歌等巨头宣布全面支持MCP，OpenAI将其集成至Agents SDK，谷歌则推出Streamable HTTP方案优化通信稳定性，推动MCP成为行业通用标准。
2025年3月：阿里云百炼平台推出首个全生命周期MCP服务，百度地图成为国内首家支持MCP协议的服务商，加速企业级生态布局。
2025年4月：魔搭社区上线MCP广场，整合5万开源模型及原子化工具，开发者可“搭积木”式调用资源，并支持多模态模型封装成 MCP 对外服务。
2025年3月技术升级：Anthropic 发布 Streamable HTTP 传输协议，解决原HTTP+SSE方案的连接恢复性与双向通信瓶颈，适配Serverless架构。
近1500款MCP服务 + MCP Bench(评估)加持 + 云端/本地部署的灵活性，让开发者能够快速验证创意、迭代应用。以MCP协议为钥匙，AI作为软件「一等用户」的崭新时代正在到来。

三、MCP 协议架构：从单向调用到上下文感知的范式跃迁

模型上下文协议（MCP）遵循客户机-主机-服务器体系结构，其中每个主机可以运行多个客户机实例。该体系结构使用户能够跨应用程序集成AI功能，同时保持清晰的安全边界并隔离关注点。MCP建立在JSON-RPC的基础上，提供了一种专注于上下文交换和客户机与服务器之间采样协调的有状态会话协议。

MCP的许多核心思想来自 Microsoft 的 LSP （Language Server Protocol），LSP 将开发工具（如IDE）与语言服务（如代码补全、语法检查）分离，使语言功能独立于编辑器实现，使 IDE 更容易添加编程语言支持。两者的核心都是通过协议解耦，提高生态系统的协作效率。他们的核心思想都是是通过标准化协议实现系统间的解耦。工具资源的语义化，协议的标准化。通过协议定义交互边界，让复杂系统通过抽象接口协作，而非直接依赖具体实现。

在这里插入图片描述
图片来源：https://blog.dailydoseofds.com/p/visual-guide-to-model-context-protocol

核心组件

MCP Host：作为容器和协调器

创建和管理多个客户端实例
控制客户端连接权限和生命周期
执行安全政策和用户同意管理
处理用户授权决策
协调进行 AI/LLM 集成和采样
管理跨客户端的上下文聚合

MCP Client：由主机创建，并与一个独立的服务器保持连接

为每个服务器维护一个有状态会话
处理协议协商和能力交换
双向路由协议消息
管理订阅和通知
维护服务器之间的安全边界

Servers: 提供特定的上下文及功能, 如资源（静态数据）、工具（可执行函数）、提示词模板

通过MCP原语公开资源、工具和提示词模板
独立工作，职责明确
通过客户端接口进行请求采样
必须安全约束
可以是本地进程或远程服务

MCP交互流程如下：

四、MCP 与函数调用对比

MCP 与 Function Call 的核心区别可概括为协议开放性、系统架构、交互模式、适用场景四个维度，两者的关系本质上是底层基础设施与上层应用接口的互补协同。MCP基于大模型的函数调用实现工具调用。

函数调用示例

import anthropic
client = anthropic.Anthropic()response = client.messages.create(model="claude-3-7",max_tokens=1024,tools=[{"name": "get_weather","description": "Get the current weather in a given location","input_schema": {"type": "object","properties": {"location": {"type": "string","description": "The city and state, e.g. San Francisco, CA",}},"required": ["location"],},}],messages=[{"role": "user", "content": "What's the weather like in San Francisco?"}],
)
print(response)

Claude 函数调用流程

为 Claude 提供工具描述和用户指令

在 API 请求中定义带有名称、描述和输入模式的工具。
包含可能需要这些工具的用户提示，例如”旧金山的天气如何？”
Claude 决定使用工具

Claude 评估是否有任何工具可以帮助解答用户的查询。
如果是，Claude 会构建格式正确的工具使用请求。
API 响应的 stop_reason 为 tool_use，表示 Claude 的意图。
提取工具输入、运行代码并返回结果

在您这边，从 Claude 的请求中提取工具名称和输入。
在客户端执行实际的工具代码。
继续对话，发送一个包含 tool_result 内容块的新 user 消息。
Claude 使用工具结果制定响应

Claude 分析工具结果，为原始用户提示制定最终响应。

注意：步骤 3 和 4 是可选的。对于某些工作流程，仅执行工具调用请求（步骤 2）就足够了，无需将结果发送回 Claude。

函数调用原理

当使用 tools 参数调用 Anthropic API 时，会根据工具定义、工具配置和任何用户指定的系统提示构建一个特殊的系统提示。构建的提示旨在指导模型使用指定的工具，并为工具提供正常运行所需的必要上下文。

函数调用系统提示示例：

In this environment you have access to a set of tools you can use to answer the user's question.
{{ FORMATTING INSTRUCTIONS }}
String and scalar parameters should be specified as is, while lists and objects should use JSON format. Note that spaces for string values are not stripped. The output is not expected to be valid XML and is parsed with regular expressions.
Here are the functions available in JSONSchema format:
{{ TOOL DEFINITIONS IN JSON SCHEMA }}
{{ USER SYSTEM PROMPT }}
{{ TOOL CONFIGURATION }}

对比维度	MCP 协议	Function Call（函数调用）
核心目标	• 标准化开放协议：基于JSON-RPC 2.0，类似AI领域的"USB-C接口" • 跨厂商兼容：支持GPT、Claude等异构模型统一接入 • 企业级安全：动态权限验证、数据加密机制	• 厂商私有接口：依赖OpenAI等厂商专属协议 • 生态割裂：切换服务商需重构调用逻辑 • 工具受限：仅支持预定义函数，无法动态发现新工具
系统架构	• 异步架构：基于SSE流式传输，支持百级并发任务 • 分布式设计：客户端-服务器模型，业务逻辑与执行分离 • 上下文管理：内置会话ID跟踪多轮交互	• 同步架构：单次请求-响应模式，适合10以下并发 • 单模型闭环：工具调用与模型服务强耦合 • 手动维护：依赖开发者拼接自然语言管理上下文
交互模式	• 异步多轮交互：支持长周期任务分阶段执行 • 结构化数据流：通过SSE实现持续数据注入 • 持久化上下文：跨会话引用历史操作与结果	• 同步单次调用：请求完成后立即返回结果 • 自然语言驱动：依赖模型理解非结构化指令 • 临时上下文：每次调用独立处理，难以跨轮复用
适用场景	• 复杂系统集成：银行风控、医疗多系统协作等企业级场景 • 异步长任务：智能家居多设备协同、自动化流程编排 • 高安全场景：动态权限控制（如患者数据分层访问）	• 快速验证：1小时内实现端到端功能原型 • 轻量任务：数学计算、天气查询等高频简单操作 • 封闭生态：特定厂商体系内扩展

开发者可根据场景选择组合策略——短期简单需求优先Function Call，长期系统采用MCP构建技术底座。

五、MCP 协议详解

在这里插入图片描述

1. MCP 设计关键原则

服务器应该非常容易构建
服务器应该是高度可组合的
服务器不应该能够读取整个会话，也不能“看到”其他服务器的会话内容
功能特性可以渐进的添加到服务器和客户端

2. 能力协商

MCP 采用用能力协商系统，客户端和服务器在初始化期间显式声明其支持的特性，决定了会话期间可用的协议特性和原语。服务器声明资源订阅、工具支持和提示模板等能力；客户端声明采样支持和通知处理等功能。

主要能力包括：

分类	能力	描述
Client	`roots`	提供文件系统支持 roots
Client	`sampling`	调用LLM sampling requests
Client	`experimental`	描述对非标准实验特性的支持
Server	`prompts`	提供提示词模板
Server	`resources`	提供资源 resources
Server	`tools`	提供工具 tools
Server	`logging`	日志功能
Server	`experimental`	描述对非标准实验特性的支持

3. 协议分层

Base Protocol: 核心JSON-RPC消息类型 (MUST)
Lifecycle Management: 连接初始化、能力协商和会话控制 (MUST)
Server Features: 服务器特性，如公开的资源、提示和工具
Client Features: 客户端特性，如采样和根文件系统
Utilities: 横切关注点，如日志记录和自动补全

这些协议层建立了清晰的关注点分离，同时支持客户机和服务器之间的丰富交互。

消息 Messages

MCP客户端和服务器之间的所有消息必须遵循 JSON-RPC 2.0 规范。协议定义了下面这些类型的消息：

Requests：用于发起操作请求必须包含唯一的ID参数
Responses：响应是对请求的应答，包含操作的结果或错误。
Notifications：通知作为单向消息发送，接收者必须不发送响应。
Batching：批量请求和通知，用于优化网络传输。

协议消息及结构定义：TypeScript schema.

MCP 生命周期

MCP 为客户机-服务器连接定义了严格的生命周期，以确保适当的能力协商和状态管理。

初始化阶段，客户端首先发起初始化请求包含支持的协议版本、支持功能、客户端基本信息。服务器回复自己支持的能力和信息。初始化成功后，客户端必须发送一个‘initialized’通知，表明它已经准备好开始正常操作。
操作阶段，客户端和服务器根据协商的功能交换消息。
关闭阶段，由其中一方（通常是客户端）关闭连接，使用底层传输机制来发出连接终止的信号。本地 Stdio 传输时通过发送 SIGKILL、SIGTERM关闭; HTTP 则通过关闭相关的HTTP连接来指示的。

超时机制，为所有发送的请求建立超时，以防止连接挂起和资源耗尽
错误处理，能处理协议版本不匹配、未能协商所需的能力、请求超时等错误

传输层

MCP 使用 JSON-RPC 对消息进行编码。JSON-RPC 消息必须使用 UTF-8 编码。当前定义了两种传输机制:

stdio, 客户端将MCP服务器作为子进程启动, 通过标准输入和标准输出的通信
Streamable HTTP, 自 2024-11-05 开始替代 HTTP+SSE transport，
服务器作为一个独立的进程运行，可以处理多个客户端连接。基于 HTTP POS T和 GET 请求，可以选择性地使用SSE用于流化多个服务器消息。

其他实用功能 Utilities

Cancellation 取消操作：支持通过通知消息可选地取消正在进行的请求。

Ping：允许任何一方验证其对等方是否仍在响应并且连接是活动的。
Progress：通过通知消息对长时间运行的操作进行可选的进度跟踪。任何一方都可以发送进度通知，以提供有关操作状态的更新。

4. 客户端功能特性

文件系统 Roots

客户端向服务器公开文件系统，Roots 定义了服务器可以在文件系统中操作的边界，允许它们了解它们可以访问哪些目录和文件。服务器可以从支持的客户机请求根列表，并在列表更改时接收通知。例如，可以提供一个工作区/项目选择器，允许用户选择服务器应该访问的目录和文件。

典型示例：

{"roots": [{"uri": "file:///home/user/projects/frontend","name": "Frontend Repository"},{"uri": "https://api.example.com/v1","name": "API Endpoint"}]
}

采样 Sampling

或者成为协同生成

MCP 为服务器通过客户端从 LLM 请求采样提供了一种标准化的方式。保持客户端对模型访问、选择和权限的控制，同时使服务器能够利用AI功能，而不需要拥有API密钥。可以理解为一种“让服务器安全地借用AI大脑”的机制。本质是"服务器通过客户端向LLM发起内容生成请求，并在用户审核控制下完成AI能力调用"的交互流程。

在统计学和机器学习中，采样（Sampling）的本质是从概率分布中提取具有代表性的数据点。例如文本生成时，模型输出的每个token都对应一个概率分布，通过温度（Temperature）或Top-P等策略选择下一个词，这一过程即称为“采样”。MCP协议沿用了这一基础概念，将LLM生成文本的行为视为对模型知识库的“信息采样”，而非简单的结果输出。

其核心特征包括：

双向交互性：服务器主动发起请求 → 用户审核修改 → LLM生成 → 结果反馈的闭环
- 参数可调控：通过temperature、maxTokens等参数控制生成随机性与规模
- 安全可控性：用户可全程干预提示词、模型选择及生成结果

模型暗示及选择

允许服务器建议特定的模型或模型族，由客户端做出最终的模型选择。

{"hints": [{ "name": "claude-3-sonnet" }, // 更喜欢 Sonnet 模型{ "name": "claude" } // 回退到其他 Claude model],"costPriority": 0.3, // 成本 Cost is less important"speedPriority": 0.8, // 速度 Speed is very important"intelligencePriority": 0.5 // 能力 Moderate capability needs
}

客户端处理这些首选项，从可用选项中选择合适的模型。

5. MCP 服务器特性

为向语言模型添加上下文提供了基本的构建块。这些原语支持客户机、服务器和语言模型之间的丰富交互：

Prompts: 预定义的提示词模板模板或指令，客户端可以发现可用的提示，检索提示的内容，并提供参数来定制提示。
Resources: 为模型提供额外的结构化数据或内容
Tools: 允许模型执行操作或检索信息的可执行函数

原语	控制权	说明	示例
Prompts	User-controlled	由用户选择调用的交互的提示词	斜杠提示指令，菜单选项
Resources	Application-controlled	由客户机附加和管理的上下文数据	文件内容，git历史
Tools	Model-controlled	LLM 可以执行操作的函数	API 请求，文件写入

提示词 Prompts

是预定义的提示词模板，可以：接受动态参数、携带资源上下文、链化多个交互、引导特定工作流、表现为UI元素（如斜杠命令）。使服务器能够定义可重用的提示模板和工作流，客户机可以轻松地将其呈现给用户和LLM。来标准化和共享常见的 LLM 交互。

提示被设计为由用户控制，这意味着它们从服务器公开给客户端，目的是让用户能够显式地选择使用它们。通常，将通过用户界面中用户发起的命令触发提示，这允许用户自然地发现和调用可用的提示。

{name: string;              // Unique identifier for the promptdescription?: string;      // Human-readable descriptionarguments?: [              // Optional list of arguments{name: string;          // Argument identifierdescription?: string;  // Argument descriptionrequired?: boolean;    // Whether argument is required}]
}

生成提示词

为了检索特定的提示，客户端发送一个“提示/获取”请求，其参数可以自动补全协议补全。

请求示例:

{"jsonrpc": "2.0","id": 2,"method": "prompts/get","params": {"name": "code_review","arguments": {"code": "def hello():\n    print('world')"}}
}

回复示例:

{"jsonrpc": "2.0","id": 2,"result": {"description": "Code review prompt","messages": [{"role": "user","content": {"type": "text","text": "Please review this Python code:\ndef hello():\n    print('world')"}}]}
}

资源 Resources

为语言模型提供上下文的数据，例如文件、数据库或特定于应用程序的信息。

工具 Tools

工具使模型能够与外部系统进行交互，例如查询数据库、调用api或执行计算。

定义工具

{name: string;          // 工具唯一标识符description?: string;  // 人类可读的功能描述inputSchema: {         // 工具参数的JSON模式定义type: "object",properties: { ... }  // 工具特定参数定义},annotations?: {        // 工具行为提示注解title?: string;      // 工具的人类可读标题readOnlyHint?: boolean;    // 若为true，表示工具不修改环境状态destructiveHint?: boolean; // 若为true，工具可能执行破坏性更新idempotentHint?: boolean;  // 若为true，相同参数重复调用无额外副作用openWorldHint?: boolean;   // 若为true，工具会与外部实体交互}
}

Request:

{"jsonrpc": "2.0","id": 2,"method": "tools/call","params": {"name": "get_weather","arguments": {"location": "New York"}}
}

Response:

{"jsonrpc": "2.0","id": 2,"result": {"content": [{"type": "text","text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy"}],"isError": false}
}

工具调用流程：

最佳实践：

提供清晰、描述性的名称和描述
对参数使用详细的JSON模式定义
在工具描述中包括示例，以演示模型应该如何使用它们
实现适当的错误处理和验证
对长期操作使用进度报告
保持工具操作的重点和原子性
记录预期的返回值结构
实现适当的超时
考虑对资源密集型操作的速率限制
日志工具的使用情况，用于调试和监控

其他设施

Completion，为提示符和资源URI提供参数自动完成建议，旨在支持类似于IDE代码补全的交互式用户体验。

Logging，用于服务器向客户端发送结构化日志消息, 客户端可以通过设置最低日志级别来控制日志记录的冗长程度。

Pagination: 分页允许服务器以较小的块生成结果，而不是一次生成所有结果, 可以避免大型数据集的性能问题。

以下MCP操作支持分页：

resources/list - 可用资源列表
resources/templates/list - 资源模板列表
prompts/list - 提示词列表
tools/list - 工具列表

六、MCP 开发示例

官方服务器示例：https://github.com/modelcontextprotocol/servers

Filesystem - 具有可配置访问控制的安全文件操作
PostgreSQL - 具有模式检查功能的只读数据库访问
Git - 用于读取、搜索和操作Git存储库的工具
支持 MCP的应用程序列表

1. 天气 MCP Server 示例

公开两个 Tool： get-alerts 和 get-forecast

from typing import Any
import httpx
from mcp.server.fastmcp import FastMCPmcp = FastMCP("weather")
NWS_API_BASE = "https://api.weather.cn"
USER_AGENT = "weather-app/1.0"async def make_nws_request(url: str) -> dict[str, Any] | None:"""发送请求"""async with httpx.AsyncClient() as client:response = await client.get(url, headers=headers, timeout=30.0)return response.json()def format_alert(feature: dict) -> str:"""格式化天气预警信息"""props = feature["properties"]return f"""Event: {props.get('event', 'Unknown')}Area: {props.get('areaDesc', 'Unknown')}Severity: {props.get('severity', 'Unknown')}Description: {props.get('description', 'No description available')}Instructions: {props.get('instruction', 'No specific instructions provided')}"""@mcp.tool()
async def get_alerts(state: str) -> str:"""获取某个地区的天气预警信息, 并格式化输出"""url = f"{NWS_API_BASE}/alerts/active/area/{state}"data = await make_nws_request(url)alerts = [format_alert(feature) for feature in data["features"]]return "\n---\n".join(alerts)@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:"""获取某个位置的天气预报"""points_url = f"{NWS_API_BASE}/points/{latitude},{longitude}"points_data = await make_nws_request(points_url)forecast_url = points_data["properties"]["forecast"]forecast_data = await make_nws_request(forecast_url)periods = forecast_data["properties"]["periods"]forecasts = []for period in periods[:5]:  # Only show next 5 periodsforecast = f"{period['name']}:Temperature: {period['temperature']}°{period['temperatureUnit']}Forecast: {period['detailedForecast']}"forecasts.append(forecast)return "\n---\n".join(forecasts)if __name__ == "__main__":# 初始化并运行mcp.run(transport='stdio')

2. 天气 MCP Client 示例：一个支持天气查询的命令行聊天机器人

在 MCP 的本地开发模式下，MCP Client 会自动启动 MCP Server，无需手动启动。MCP Client 在连接本地服务端时，会通过 uv run client.py path/to/server.py 命令将 MCP Server 作为子进程启动。此时服务端脚本（如 server.py）会由客户端进程托管。客户端与服务端通过标准输入输出（stdio）建立通信管道，采用 JSON-RPC 2.0 协议交换数据，这种设计使开发者无需关心进程间通信细节。

import asyncio
from typing import Optional
from contextlib import AsyncExitStack
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
from anthropic import Anthropic
from dotenv import load_dotenvload_dotenv()  # 从 .env 加载环境变量, ANTHROPIC_API_KEY=<your key here># 基于 Claude + mcp client 的客户端封装
class MCPClient:def __init__(self):self.session: Optional[ClientSession] = Noneself.exit_stack = AsyncExitStack()# 使用 Claude 大模型服务self.anthropic = Anthropic()async def connect_to_server(self, server_script_path: str):"""连接 MCP 服务器，server_script_path: 服务器脚本的路径 (.py or .js)"""command = "python" if is_python else "node"# 指定服务端启动命令参数server_params = StdioServerParameters(command=command,args=[server_script_path],env=None)stdio_transport = await self.exit_stack.enter_async_context(stdio_client(server_params))self.stdio, self.write = stdio_transportself.session = await self.exit_stack.enter_async_context(ClientSession(self.stdio, self.write))await self.session.initialize()# 打印可用的 toolsresponse = await self.session.list_tools()tools = response.toolsprint("\nConnected to server with tools:", [tool.name for tool in tools])async def process_query(self, query: str) -> str:"""使用 Claude 和 可用工具处理用户消息"""messages = [{ "role": "user", "content": query}]response = await self.session.list_tools()# 通过函数调用使用工具available_tools = [{ "name": tool.name,"description": tool.description,"input_schema": tool.inputSchema} for tool in response.tools]# 发送 Claude API 请求response = self.anthropic.messages.create(model="claude-3", max_tokens=1000, messages=messages, tools=available_tools)# 处理响应和处理工具调用final_text = []for content in response.content:if content.type == 'text':final_text.append(content.text)elif content.type == 'tool_use':tool_name = content.nametool_args = content.input# 通过 MCP 服务器执行天气查询result = await self.session.call_tool(tool_name, tool_args)final_text.append(f"[Calling tool {tool_name} with args {tool_args}]")# 将工具查询结果返回给大模型获取进一步回复if hasattr(content, 'text') and content.text:messages.append({"role": "assistant", "content": content.text})messages.append({"role": "user", "content": result.content})response = self.anthropic.messages.create(model="claude-3", max_tokens=1000, messages=messages)final_text.append(response.content[0].text)return "\n".join(final_text)# 处理命令行对话，用户输入及回复async def chat_loop(self):"""Run an interactive chat loop"""print("\nMCP Client Started!")print("Type your queries or 'quit' to exit.")while True:try:query = input("\nQuery: ").strip()if query.lower() == 'quit':breakresponse = await self.process_query(query)print("\n" + response)except Exception as e:print(f"\nError: {str(e)}")async def cleanup(self):await self.exit_stack.aclose()# 主函数
async def main():if len(sys.argv) < 2:print("Usage: python client.py <path_to_server_script>")sys.exit(1)client = MCPClient()try:await client.connect_to_server(sys.argv[1])await client.chat_loop()finally:await client.cleanup()
if __name__ == "__main__":import sysasyncio.run(main())

运行

uv run client.py path/to/server.py # python server
uv run client.py path/to/build/index.js # node server

在这里插入图片描述

七、行业应用案例

医疗领域，动态知识库整合：
MCP 连接 PubMed（医学文献）、Epic EHR（电子病历）、FDA 药品数据库。
场景：医生问：“患者有糖尿病史，近期肌酐升高，推荐治疗方案？”
LLM 自动调用工具：从 EHR 获取患者用药记录 → 2. 检索最新治疗指南 → 3. 生成个性化建议（避开禁忌药物）。
金融合规，实时风控系统：
MCP 整合 Bloomberg 数据、内部交易记录、反洗钱规则库。
场景：AI 监测可疑交易时，自动调用客户 KYC 信息 → 2. 匹配黑名单 → 3. 生成合规报告并邮件通知审计部门。
优势：相比传统规则引擎，AI 可理解非结构化数据（如邮件内容）。
教育智能化，个性化学习助手：
工具链：MOOC 平台 + 题库系统 + 学生行为分析数据库。
流程：学生提问后，AI 自动检索知识点讲解视频（MCP 调用 MOOC API）推送相似习题（题库工具），根据历史错题调整难度（数据分析工具）。

八、大模型计价

大模型的价格区分提示（Prompt）和补全（Completion）主要是因为这两者在模型处理过程中消耗的资源和计算成本不同。

提示（Prompt）：用户输入给模型的信息，用于引导模型生成响应。提示可以包含指令、上下文、样本等元素。对于模型来说，接收和理解提示是一个过程，但通常这个过程不会消耗太多的计算资源，除非提示非常长或复杂。
补全（Completion）：模型根据提示生成的输出内容。生成补全往往比处理提示需要更多的计算资源，因为模型需要综合其训练得到的知识来生成连贯且相关的回复。生成文本长度越长，通常所需的计算资源越多，因此成本也更高。

九、如何使用 LLM 快速开发 MCP 服务器

1. 收集必要的文档来帮助 LLM 理解MCP

获取并复制协议全文，复制 MCP SDK（TypeScript或Python）的README文件和其他相关文档。把这些文件粘贴到你和AI 编程助手的对话上下文中。

2. 清楚地描述你的 MCP 服务器

您的服务器将公开哪些资源
它将提供什么工具
它应该提供的提示
它需要与什么样的外部系统进行交互

3. 与 LLM 进行结对编程

首先从核心功能开始，然后迭代添加更多功能
让AI解释代码中你不懂的部分
根据需要要求修改或改进
让AI帮你测试服务器和处理边缘情况

4. 建议

将复杂的服务器拆分成更小的部分
在继续之前彻底测试每个组件
牢记安全性—验证输入并适当限制访问
为将来的维护做好代码文档
严格遵循MCP协议规范

十、MCP 面临的核心挑战及解决方案探索

安全风险指数级扩大
• 供应链攻击泛滥：第三方MCP服务器代码审核缺失（如恶意工具包伪装成合法工具），通过动态工具发现机制快速传播恶意功能（如网页10描述的"工具投毒攻击"）。
• 权限管理失控：MCP当前仅支持会话级权限控制，当集成上百个工具时，企业难以实施细粒度访问策略（如网页3提到的"删除文件工具与读取日志工具同权限级"）。
• 协议层漏洞利用：MCP早期版本未强制TLS加密，导致中间人攻击可窃取敏感上下文数据（如网页9提到的"会话劫持"风险）。
性能瓶颈与资源消耗
• 上下文过载：每个MCP工具描述平均占用200-500 tokens，集成50个工具将使单次交互消耗10k+ tokens，导致模型响应延迟上升（网页3实测显示工具数超过60时Claude性能下降30%）。
• 异步任务堆积：MCP支持的SSE流式传输在百级并发时（如电商大促场景），服务器资源占用率可达API模式的3倍以上。
协议碎片化与兼容性危机
• 厂商定制化协议：部分厂商在MCP基础上扩展私有字段（如添加视频流处理参数），破坏跨平台兼容性（类似网页1提到的"私有协议困局"重现）。
• 版本迭代冲突：MCP规范更新频率快（2025年已发布4个主版本），新旧工具混用导致功能异常（如网页11提到的"静默重定义攻击"）。
工具生态混乱
• 工具命名冲突：不同MCP服务器注册同名工具（如"send_email"），引发不可预测的行为（网页3实测工具冲突率高达12%）。
• 维护成本激增：企业需同时维护API网关和MCP网关，技术栈复杂度翻倍（网页7指出混合架构的运维成本是纯API模式的1.8倍）。

应对建议

安全加固方向
• 采用MCP网关实施统一鉴权（如Zapier方案），引入零信任架构验证每个工具调用链
• 推动工具签名验证标准（如"MCP证书颁发机构"），阻断未签名工具执行
性能优化路径
• 开发分级路由机制（如网页3提出的"拓扑感知分层"），仅向模型暴露当前场景相关工具
• 推广MCP响应压缩算法（如Protobuf二进制编码），降低token消耗量
生态治理策略
• 建立官方工具注册中心，实施工具名称唯一性校验
• 推动IEEE标准化进程，约束厂商私有扩展行为
• 云托管服务：推出"一键部署"MCP云服务，类似AWS Lambda的无服务器托管方案
• 智能工具推荐：基于标签分类和使用频率构建工具图谱（如金融领域整合20+数据源）

十一、与 A2A 协议的关系

在这里插入图片描述

A2A 是一个开放协议，是对 Anthropic 的模型上下文协议 (MCP) 的补充，MCP 为智能体提供了有用的工具和上下文，提供了一种让智能体相互协作的标准方式。Google 根据在扩展智能体系统方面的内部专业知识，Google 设计了 A2A 协议，以应对在为客户部署大规模、多智能体系统时遇到的挑战。Google 相信，这种通用的互操作性对于充分发挥协作 AI 智能体的潜力至关重要。

What (是什么): Agent2Agent (A2A) 是一个由 Google 及合作伙伴倡导的开放协议，旨在让来自不同供应商或基于不同框架构建的异构 AI Agent（智能体）能够进行安全的通信和任务协作。它本质上是为 AI Agent 交互定义的一套标准“沟通语言”和框架。

Why (为什么需要): 为了解决当前 AI Agent 生态普遍存在的“智能孤岛”问题。缺乏互操作性阻碍了构建能够跨越不同 Agent 系统边界、协同完成复杂任务的应用。A2A 的目标是促进形成一个开放、协作的 Agent 生态系统，打破技术壁垒和供应商锁定，并为企业级集成提供基础。借助 A2A 协议，开发者可以构建能够与使用该协议构建的任何其他智能体建立连接的智能体，让用户能够灵活地组合来自各种提供商的智能体。至关重要的是，企业可以受益于这种标准化方法，跨不同平台和云环境管理其智能体。

How (如何实现): A2A 基于成熟的标准网络技术（如 HTTP, JSON-RPC 2.0, SSE）。它定义了一套核心概念和机制，包括：用于服务发现和能力描述的 Agent Card；用于管理协作工作单元及其状态的 Task；用于承载多模态信息交换的 Message 和 Part；以及用于表示最终成果的 Artifact。协议强调异步优先、模态无关、安全可靠以及不透明执行的交互原则，并通过标准化的方法（如 tasks/send, tasks/get）来驱动协作流程。

A2A 的设计原则：

拥抱智能体能力：A2A 聚焦于让智能体以其自然、非结构化的方式进行协作，即使彼此没有共享内存、工具和上下文，也能高效协作。我们将实现真正的多智能体场景，不再将智能体仅仅看作是“工具”。
依托现有标准构建：该协议是基于 HTTP、SSE、JSON-RPC 等当下主流标准构建而成，这意味着其能够更轻松地与企业当前日常使用的 IT 堆栈进行集成。
默认安全：A2A 旨在支持企业级身份验证和授权，并在发布时与 OpenAPI 的身份验证方案保持对等。
支持长时间运行的任务：我们设计的 A2A 非常灵活，支持各种场景，在这些场景中，它可以出色地完成从快速任务到深入研究（在有人类参与的情况下可能需要数小时甚至数天的时间才能完成）的所有任务。在整个过程中，A2A 可以向用户提供实时反馈、通知和状态更新。
模式不受限：智能体世界不仅限于文本，这就是为什么我们将 A2A 设计为支持各种模式，包括音频和视频流。

关键功能

A2A 方便了“客户端”智能体与“远程”智能体之间的通信。客户端智能体负责制定和传达任务，而远程智能体负责执行这些任务，力图提供正确的信息或采取正确的行动。这种交互涉及几个关键功能：

能力发现：智能体可以使用 JSON 格式的“智能体卡”来宣传其能力，从而使客户端智能体能够识别出能执行任务的最佳智能体，并利用 A2A 与远程智能体进行通信。
任务管理：客户端智能体与远程智能体之间的通信以完成任务为导向，智能体在其中努力完成最终用户的请求。该“任务”对象由协议定义，并且具有生命周期。任务可以立即完成，而对于长时间运行的任务，每个智能体都可以进行通信，以便彼此之间保持同步，了解任务完成情况的最新状态。任务的输出被称为“工件”。
协作：智能体可以相互发送信息，交流上下文、回复、工件或用户指令。
用户体验协商：每条消息都包含“部件”，“部件”是一个完整的内容片段，例如生成的图像。每个部件都有指定的内容类型，允许客户端和远程智能体协商所需的正确格式，并明确包括用户界面功能的协商，如 iframe、视频、网页表单等。

MCP 与 A2A 对比:

特性	Agent2Agent (A2A)	Model Context Protocol (MCP)
主要交互对象	Agent 到 Agent (智能体之间的协作对话)	Agent 到 Tool/Resource (智能体调用外部能力/数据)
交互性质	协作性、协商性、状态驱动、可能长时间运行、多模态信息传递	调用性、请求-响应式、通常更结构化、面向具体功能执行
核心目标	实现异构 Agent 间的互操作性与任务协同	标准化 Agent 对外部工具和上下文资源的访问与使用
抽象层级	应用层/协作层协议	更偏向于 Agent 内部决策与执行层面的工具接口协议
解决的核心问题	Agent 之间的“沟通障碍”和“协作壁垒”	Agent 调用外部工具时的“接口混乱”和“集成复杂”
典型场景	任务委派、多 Agent 联合决策、复杂工作流编排、人机协同	API 调用、数据库查询、文件读写、代码执行、RAG 数据检索

十二、MCP 价值意义

对于AI厂商，专注算法，协议即生态，MCP成为"技术插座"，模型只需兼容协议即可调用数千工具服务（如GitHub/Slack）。让大模型厂商能够专注于核心算法优化，而非重复开发工具适配层。
对于技术服务提供商，可以构建以安全、标准化的方式向 LLM 应用公开数据和功能的服务器。开发者将功能封装为 MCP Server 后，就能被所有兼容协议的AI应用调用。如PostgreSQL官方开发的数据库Server已被500多个AI应用集成，而无需针对每个模型单独适配。
应用开发者，MCP打破了技术能力的边界，通过协议标准化，开发者无需理解底层技术细节即可组合各类工具资源，MCP的协议兼容性使得自然语言交互可直接映射到具体功能实现。
企业用户：MCP协议通过标准化接口打通ERP、MES、SCM等核心系统，实现生产、库存、物流数据的实时互通。例如，企业通过自然语言指令（如“生成华东仓库补货建议”）直接触发供应链决策，替代传统GUI的多级菜单操作。
个人用户：MCP协议将复杂技术交互简化为口语化指令，用户可通过“找附近人均200元的川菜馆”等自然语言直接调用地图、点评数据库等多工具组合服务
。智能助手借助可无缝集成日历、邮件、云文档等工具，实现“一句话管理日程+预订餐厅+生成会议纪要”的端到端服务。

MCP重构AI技术供应链分工，通过协议层统一工具调用标准，使各角色专注核心价值创造，推动生态协同效率量级提升。

十三、产业生态预测

MCP平台生态的必然性：AI时代的"新应用商店"

MCP协议通过标准化工具调用和上下文管理，天然具备构建平台生态的潜力。从现有趋势看，类似App Store的MCP平台必然会出现，其核心驱动力包括：

协议标准化需求：MCP的"USB-C式接口"特性，要求统一工具注册、发现与调用机制，形成类似iOS开发者门户的生态中枢。
开发者变现刚需：当前已有案例显示，工具型MCP服务订阅费可达$50-200/月（如MiniMax多模态服务），但缺乏统一分发渠道。
企业级服务整合：支付宝、飞书等企业通过私有MCP服务实现内部数据流通，但跨平台协作需公共市场。

在这里插入图片描述

总结

MCP 通过技术标准化、生态开放化、应用场景化，解决了AI开发中的“适配地狱”问题，释放了开发者的生产力，同时为巨头构建护城河、中小企业创新提供了基础设施。其本质是AI领域的“工业化革命”，将分散的工具链整合为可规模化的生态系统，最终推动技术从实验室走向千行百业
。随着协议完善与社区壮大，MCP或将成为AI时代的“水电煤”，成为智能社会的基础设施之一。