MCP学习笔记

MCP: AI时代的HTTP，一个统一的“AI插座”。
把MCP理解为NPM包：能力标准化 -> 能力即服务 -> 能力市场 -> 新的商业模式。
MCP本质上是一个集成协议/技术.

[[learning/PPT/AI 编程：从模糊需求到精准实现/DeepResearch]]

Function Calling VS. MCP VS. A2A

这是三个层级的东西，简单来说：
Level 1: Function Calling 解决”怎么调用外部函数”，是具体的实现
Level 2: MCP 解决“大量外部工具如何高效接入”，是一个协议，不是具体的实现
Level 3: Al Agent 解决”如何自主完成复杂任务”，是一种架构

类比

Level 1: Function Calling ≈ API调用机制

软件工程类比：类似于程序调用外部API或SDK的具体实现方式
系统概念：相当于系统间接口集成(Interface Integration)
设计模式类比：类似于适配器模式(Adapter Pattern)，将外部功能转换为可用形式
技术实现：类似于RPC(远程过程调用)或WebHook的具体实现
记忆要点：关注”如何调用“的技术细节

Level 2: MCP ≈ 接口规范/通信协议

软件工程类比：类似于RESTful API规范或OpenAPI/Swagger文档
系统概念：相当于ESB(企业服务总线)或API网关(API Gateway)
设计模式类比：类似于外观模式(Facade Pattern)，提供统一接口
技术实现：类似于HTTP协议、gRPC协议等通信标准
记忆要点：关注”如何标准化连接“的协议规范

Level 3: AI Agent ≈ 微服务架构/自治系统

软件工程类比：类似于微服务架构或自治系统(Autonomous System)
系统概念：相当于服务编排(Service Orchestration)或业务流程管理(BPM)
设计模式类比：类似于命令模式(Command Pattern)和策略模式(Strategy Pattern)的结合
技术实现：类似于Kubernetes中的Operator模式或Serverless架构
记忆要点：关注”自主决策执行“的系统智能

主要区别

核心关注点不同：
- Function Call：关注模型与外部功能的连接
- MCP：关注模型接收和处理上下文的标准化方式
- A2A：关注多个代理间的协作与通信
实现层面不同：
- Function Call：接口层面的实现，专注于功能扩展
- MCP：协议层面的实现，专注于标准化交互
- A2A：架构层面的实现，专注于系统协作
使用场景不同：
- Function Call：当需要执行特定外部任务时使用
- MCP：当需要标准化模型与上下文交互时使用
- A2A：当需要多个专业化代理协作解决问题时使用

这些技术通常可以组合使用，比如在符合MCP协议的系统中，代理可以使用Function Call来访问外部资源，同时多个代理可以通过A2A框架进行协作。

MCP VS REST ful HTTP

The Model Context Protocol (MCP) lets you build servers that expose data and functionality to LLM applications in a secure, standardized way. Think of it like a web API, but specifically designed for LLM interactions. MCP servers can:

Expose data through Resources (think of these sort of like GET endpoints; they are used to load information into the LLM’s context)
Provide functionality through Tools (sort of like POST endpoints; they are used to execute code or otherwise produce a side effect)
Define interaction patterns through Prompts (reusable templates for LLM interactions)
And more!

执行流程

Function Call 执行流程

flowchart LR

%% Function Call 流程

FC1[用户输入查询] --> FC2[AI模型解析查询]

FC2 --> FC3{需要调用外部功能?}

FC3 -->|不需要| FC7[模型直接生成回复]

FC3 -->|需要| FC4[确定要调用的函数]

FC4 --> FC5[构造函数参数]

FC5 --> FC6[执行函数调用]

FC6 --> FC8[接收函数返回结果]

FC8 --> FC9[处理函数返回数据]

FC9 --> FC10[整合数据生成回复]

FC7 --> FC11[返回回复给用户]

FC10 --> FC11

Function Call 允许AI模型调用外部函数，其完整流程包括：

用户输入查询：用户向AI系统提出需要解决的问题或任务
AI模型解析查询：模型分析用户的输入内容和意图
判断是否需要调用外部功能：模型决定是直接回答还是需要外部功能支持
- 如不需要：模型直接生成回复
- 如需要：进入函数调用流程
确定要调用的函数：从可用函数列表中选择最合适的函数
构造函数参数：根据用户需求和函数定义准备必要的参数
执行函数调用：将函数名和参数发送到外部系统执行
接收函数返回结果：等待并获取函数执行的结果数据
处理函数返回数据：解析、转换或提取返回数据中的关键信息
整合数据生成回复：将函数执行结果与模型知识结合形成完整回答
返回回复给用户：向用户展示最终结果

MCP (Model Context Protocol) 执行流程

flowchart LR

MCP1[准备结构化提示模板] --> MCP2[接收用户输入]

MCP2 --> MCP3[解析输入,映射到协议结构]

MCP3 --> MCP4[根据协议标准构造上下文]

MCP4 --> MCP5[将上下文传递给AI模型]

MCP5 --> MCP6[模型根据协议规则处理上下文]

MCP6 --> MCP7[模型生成符合协议格式的响应]

MCP7 --> MCP8[解析响应,提取关键信息]

MCP8 --> MCP9[根据协议规则格式化输出]

MCP9 --> MCP10[返回标准化响应给用户]

MCP是一种标准化AI模型与上下文交互的协议，其执行流程为：

准备结构化提示模板：根据协议规范定义交互模板和格式
接收用户输入：获取用户的原始查询或指令
解析输入，映射到协议结构：将用户输入转换为符合协议的格式
根据协议标准构造上下文：按照协议规定组织上下文信息
将上下文传递给AI模型：以标准化格式传送到模型
模型根据协议规则处理上下文：模型按照协议定义的方式理解和处理信息
模型生成符合协议格式的响应：输出符合协议规定结构的回答
解析响应，提取关键信息：从模型响应中提取有效内容
根据协议规则格式化输出：将响应转换为标准化的输出格式
返回标准化响应给用户：向用户展示最终处理结果

A2A (Agent-to-Agent) 执行流程

flowchart LR

A2A1[用户提交复杂任务] --> A2A2[任务协调器分析任务]

A2A2 --> A2A3[任务分解为子任务]

A2A3 --> A2A4[为子任务分配专业代理]

A2A4 --> A2A5[代理1处理子任务1]

A2A4 --> A2A6[代理2处理子任务2]

A2A4 --> A2A7[代理3处理子任务3]

A2A5 --> A2A8[代理间交换中间结果]

A2A6 --> A2A8

A2A7 --> A2A8

A2A8 --> A2A9[协调器整合代理结果]

A2A9 --> A2A10{结果完整?}

A2A10 -->|否| A2A11[派发后续子任务]

A2A11 --> A2A4

A2A10 -->|是| A2A12[生成最终结果]

A2A12 --> A2A13[返回完整结果给用户]

A2A实现了多个AI代理之间的协作，其完整流程为：

用户提交复杂任务：用户提出需要多步骤或多专业知识解决的问题
任务协调器分析任务：中央协调系统分析整体任务需求和复杂度
任务分解为子任务：将复杂任务拆分为可独立处理的子任务
为子任务分配专业代理：根据各代理专长分配子任务
代理处理子任务：各专业代理并行或顺序处理分配的子任务
代理间交换中间结果：各代理共享处理结果和中间信息
协调器整合代理结果：中央系统汇总和整合各代理的处理结果
判断结果是否完整：评估当前结果是否满足最终目标
- 如不完整：派发后续子任务，返回到分配代理步骤
- 如完整：进入结果生成阶段
生成最终结果：整合所有代理输出形成完整解决方案
返回完整结果给用户：向用户提供最终答案或解决方案

这三种技术各自针对不同的AI交互需求，但它们也可以结合使用以创建更强大、更灵活的AI系统。例如，在A2A系统中的代理可以使用Function Call来调用外部功能，同时整个系统可以遵循MCP协议来标准化交互格式。

使用实践

Cursor+MCP快速安全地实现项目更新

https://zhuanlan.zhihu.com/p/29507951515?utm_psn=1885949634326808198

Figma MCP 让cursor 读取到更准确的 figma 文件信息，生成的 code 更加精准

https://github.com/GLips/Figma-Context-MCP

启动：

1	`npx figma-developer-mcp --figma-api-key=<API Key>`

应用的想法

解决可视化组件库的易用性问题

mcp配合cursor能解决使用组件缺失文档的问题

生成可视化图表

这个是基于AntV的：
https://github.com/antvis/mcp-server-chart

AI选择MCP Server的实现原理

通过 Prompt指令 把所有可以用的MCP Server的「说明书」一股脑扔给 AI。

https://www.zhihu.com/question/1890546618509538123
在Cline源码中搜：Tool Use Formatting

开发MCP

MCP provides a standardized way to connect AI models to different data sources and tools.

一些概念

server是跑在本地的服务。

What’s happening under the hood

When you ask a question:

The client sends your question to Claude
Claude analyzes the available tools and decides which one(s) to use
The client executes the chosen tool(s) through the MCP server
The results are sent back to Claude
Claude formulates a natural language response
The response is displayed to you!

官方文档

https://modelcontextprotocol.io/introduction

MCP TypeScript SDK

https://github.com/modelcontextprotocol/typescript-sdk

Tutorial

https://modelcontextprotocol.io/quickstart/server

安装方式

Cursor

Claude

https://github.com/modelcontextprotocol/servers/tree/main/src/brave-search

一些有意思的MCP

Chrome Devtools MCP

https://github.com/ChromeDevTools/chrome-devtools-mcp

常见问题

MCP Client如何获取MCP Server的工具列表？

MCP客户端通过Model Context Protocol（模型上下文协议）与MCP服务器通信获取工具列表。具体来说：
1.MCP Client使用JSON-RPC协议向服务器发送list_tools请求，这个请求符合ListToolsRequestSchema的格式。
2.MCP Server在接收到这个请求后，会返回所有可用的工具列表。比如：

1
2
3

this.server.setRequestHandler(ListToolsRequestSchema, async () => ({
tools: Object.values(Charts).map((chart) => chart.tool),
}));

3.服务器提取所有图表模块中定义的工具（chart.tool）并返回给客户端。每个工具包含以下信息：

name: 工具名称（如generate_bar_chart）
description: 工具描述

inputSchema: 输入参数的JSON Schema定义
4.通信通道是通过标准输入/输出（stdio）建立的，这在src/services/stdio.ts中配置：

export async function startStdioMcpServer(server: Server): Promise<void> {
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("MCP Server Chart running on stdio");
}

5.当MCP客户端需要使用某个工具时，它会发送call_tool请求（遵循CallToolRequestSchema格式），包含工具名称和参数。

如何解决tools信息太多导致Prompt过长的问题？

按照MCP的机制，tools的描述信息会给到LLM，如果某个MCP Server返回的tools过多，会导致LLM的Prompt过长，进而增大了token消耗。

LLM的回答

这是MCP协议在实际应用中面临的一个实际挑战，具体影响包括：

token消耗增加：

每个工具都包含名称、描述和输入模式(JSON Schema)
所有这些信息都会作为上下文传递给LLM
工具数量越多，消耗的token就越多，这直接增加了API调用成本

上下文窗口挤压：

LLM的上下文窗口是有限的(如Claude的100K token)
工具描述占用过多空间后，留给实际对话内容的空间就减少了
这可能导致LLM无法访问较早的对话历史记录

响应质量问题：

过多的工具描述可能稀释LLM对重要信息的关注
可能导致工具选择不准确或不必要的工具调用

为解决这个问题，一些实现采取了以下策略：

动态工具加载：根据对话内容动态决定加载哪些工具，而不是一次性加载所有工具
工具分组：将相关工具组织成功能组，根据需要只加载特定组
工具描述优化：使用更简洁但仍足够清晰的工具描述
工具筛选机制：在客户端层面预先筛选可能需要的工具，而不是将所有工具都传递给LLM
一些专业解决方案，如RouteLLM等路由框架，正是为了解决这类问题而设计的，它们能够根据查询内容智能决定使用哪些工具，从而优化token使用和性能。

这也是为什么在设计MCP服务器时，应该考虑将相关功能整合为少量但功能强大的工具，而不是提供大量细粒度工具的原因之一。

我的思考

1、采用链路拆分的方式去解决。
这个方案似乎并未解决问题。

2、将信息从Prompt转为SFT到模型内部。

Client closed

https://github.com/GLips/Figma-Context-MCP/issues/42
是因为JSON格式做过更改，最新的格式是这样的：

{
  "mcpServers": {
    "figma-developer-mcp": {
      "url": "http://localhost:3333/sse",
      "env": {
        "API_KEY": "YOUR API KEY"
      }
    }
  }
}

Pro用户仍然提示“Please upgrade to Pro to continue.”

是代理block了HTTP2的缘故：
https://forum.cursor.com/t/cursor-tab-not-working-wants-upgrade-but-am-already-pro/20737/14

关闭即可。

如何查看日志

If you’re running the MCP in a code editor like Cursor, there are MCP-specific logs that provide more context on any errors. In Cursor, you can find them by clicking CMD + Shift + P and looking for Developer: Show Logs.... Within the show logs window, you can find Cursor MCP—copy and paste the contents there into the bug report.

资讯

OpenAI官宣支持Anthropic推出的大模型上下文协议MCP

https://mp.weixin.qq.com/s/KFLNI4rcQ8zOqAO2IIcKLg

资料

Cursor官方的MCP列表：
docs.cursor.com/tools

(精)MCP：能力即服务
https://mp.weixin.qq.com/s/MGthNyHHlD4lERzDluMc1g

这让我想起了HTTP在90年代的角色。HTTP不是第一个网络协议，也不是最复杂的，但它简单、足够好，得到了广泛支持。现在MCP可能正走在类似的道路上。

在其核心，MCP解决了两个大问题：它为LLM提供了完成可能从未见过的任务的正确上下文集；它用一个干净的、模块化的模型取代了N×M定制集成，在这个模型中，工具暴露标准接口（服务器），可由任何AI agent（客户端）使用。

这里有个深刻的洞察：我们正在见证"能力标准化"的诞生。就像USB标准化了设备连接，MCP正在标准化AI agent能力。任何工具都可以暴露自己的功能，任何AI agent都可以使用这些功能，不需要定制集成。

声明式基础设施：

1	`"声明式基础设施"。AI agent不需要知道如何实现用户认证，它只需要声明"这个应用需要用户认证"，然后让合适的原语服务处理具体实现。`

MCP介绍：
一文带你弄懂 MCP 的核心原理

同事整理的MCP资源：
http://cf.myhexin.com/pages/viewpage.action?pageId=1317621743

https://zhuanlan.zhihu.com/p/28320655477

使用文档：
https://docs.cursor.com/context/model-context-protocol

资源网站：
GitHub官方资源中心
https://github.com/modelcontextprotocol/servers

Awesome MCP Servers
https://github.com/punkpeye/awesome-mcp-servers

Cursor.directory（官方提示词与插件库）
https://cursor.directory/mcp

Smithery.ai（懒人配置站）
https://smithery.ai/

11个MCP资源库
https://mp.weixin.qq.com/s/DBhC3un8gnrahZZZW7_ISQ

Cursor通过MCP调用Dify工作流
https://mp.weixin.qq.com/s/AQ1cWjWSv0fNebVSM3gJPA

MCPify.ai:一句话构建一个MCP
https://mp.weixin.qq.com/s/Ahl77ddoaQFWrp6--Pb9CQ

#AI