© 2026 志趣 ZhiQu AI 开发者知识沉淀社区 · 记录每一次踩坑,沉淀每一个解决方案
MCP 协议与生态指南:Claude Code、Cursor 与开源工具链实战 — 志趣 ZhiQu
返回首页MCP 协议与生态 节点 MCP 协议与生态指南:Claude Code、Cursor 与开源工具链实战
本文是《MCP 是什么?从零理解 Model Context Protocol 》的进阶篇。入门篇讲了「MCP 是什么」,这篇讲「怎么用、怎么选、怎么建、往哪走」。建议先读过入门篇再看这篇,当然也可以直接往下——第一章有 101 回顾。
目录:
MCP 协议 101 回顾 + 2026 生态快照
MCP Server 分类图谱
MCP 协议技术骨架
Claude Code / Cursor / VS Code MCP 横向对比
从零构建 MCP Server (含 §5.7 开发常见坑点)
竞争格局与标准化进展
风险、限制与未来路线图
1. MCP 协议 101 回顾 + 2026 生态快照
1.1 一句话理解 MCP
如果说 LLM 是 AI 应用的「大脑」,那 MCP(Model Context Protocol)就是连接大脑与外部世界的 「USB-C 接口」 。它是一个开放协议,标准化了 AI 模型如何发现和调用外部工具、访问外部数据——就像 USB-C 统一了充电、数据传输和视频输出的物理接口一样,MCP 统一了 AI 工具生态的「逻辑接口」。
2024 年 11 月由 Anthropic 发布后,MCP 迅速被 Claude Code、Cursor、VS Code、Zed、Continue 等主流 AI 编码工具采用。更关键的是——连 OpenAI 也在 2025 年 3 月宣布 ChatGPT 全面支持 MCP,Google Gemini 紧随其后在 4 月接入。到 2025 年 12 月,MCP 被正式捐赠给 Linux Foundation 旗下的 Agentic AI Foundation 进行独立治理。
这意味着 MCP 已经不再是「Anthropic 的协议」——它是整个 AI 行业的公共基础设施。
1.2 核心架构:Client → Protocol → Server
MCP 的架构可以用三层模型理解:
Host(宿主应用:Claude Code / Cursor / VS Code)
│
├── MCP Client: GitHub 连接
│ └── ⚡ JSON-RPC over stdio ──→ GitHub MCP Server(独立进程)──→ GitHub API
│
├── MCP Client: Filesystem 连接
│ └── ⚡ JSON-RPC over stdio ──→ Filesystem MCP Server(独立进程)──→ 本地文件系统
│
└── MCP Client: Brave Search 连接
└── ⚡ JSON-RPC over stdio ──→ Brave Search MCP Server(独立进程)──→ Brave Search API
Host(宿主应用) :你正在使用的 AI 工具——Claude Code、Claude Desktop、Cursor 等。它负责管理 MCP 客户端的生命周期和安全策略。
Client(协议客户端) :宿主内部的 MCP 协议实现,与 Server 建立一对一连接,负责消息路由和状态管理。
本文原创发布于 zhiqu.ac,未经书面许可禁止全文转载、采集、商用。转载须完整标注原文链接与作者。
Server(服务端) :暴露特定能力的轻量级程序——可以读写文件、查询数据库、搜索网页、控制浏览器等。每个 Server 专注于一类能力。关键设计思想:一个 Host 可以同时连接多个 MCP Server,每个 Server 独立运行在自己的进程中,互不干扰。
1.3 三个核心原语 MCP 对外暴露三层能力,分别对应不同的交互模式:
原语 方向 用途 示例 Tools LLM → Server 让 AI 执行 操作 github_create_issue、filesystem_write_fileResources Server → LLM 让 AI 读取 数据 file:///src/main.ts、postgres://users/tablePrompts Server → LLM 预置提示模板 「帮我总结这个 PR」、代码审查清单
Tools 是 MCP 的核心能力——AI 决定「我想做什么」,然后调用对应的 Server 工具去执行。工具调用是模型驱动的:LLM 根据上下文自主选择何时、如何调用。
Resources 是反向的数据流——Server 把文件系统、数据库、API 响应等数据以结构化方式暴露给 LLM,就像给 AI 装上了一个「通用数据连接器」。
Prompts 是辅助层——Server 可以提供预定义的提示模板,帮助用户更快地引导 AI 完成常见任务。
理解这三者的区别,就掌握了 MCP 能力模型的 80%。
1.4 2026 年 6 月生态快照 截至 2026 年 6 月,MCP 生态的关键数字:
指标 数据 公开 MCP Server 数量 13,000 ~ 23,000+ ¹官方参考 Server 仓库 GitHub Stars ~87,000 整个 MCP 生态累计 Stars 300,000+ SDK 月下载量(2026.03) 9,700 万次 ²近 6 个月增长率 300% 支持 MCP 的主流客户端 Claude Code、Claude Desktop、Cursor、VS Code、Zed、Continue、Sourcegraph Cody、Windsurf 等 企业采用 Anthropic、OpenAI、Google、Microsoft、AWS、Salesforce 均已官方支持
从 2024 年 11 月发布至今仅 19 个月,MCP 已经从单一产品特性演变为 AI 工具链的通用基础设施。SDK 月下载量从发布时的约 200 万增长到 9700 万——这个速度在开发者工具领域是罕见的,甚至超过了 Kubernetes 的早期采用曲线。
¹ MCP Server 数量因统计口径不同存在差异:GitHub 搜索 mcp-server 主题标签约 13,000 个,mcp.so 等聚合平台收录约 23,000+ 个(含重复与低质量项目)。
² SDK 下载量数据来源:npm 官方统计(@modelcontextprotocol/sdk,2026 年 3 月)。
2. MCP Server 分类图谱
2.1 五大分类 面对上千个 MCP Server,一个清晰的分类体系是入门的捷径。按功能领域可将 MCP Server 分为五大类:
分类 核心能力 典型用户 📁 文件与数据 读写文件、查询数据库 所有开发者 🌐 网络与 API HTTP 请求、搜索、平台集成 需要联网信息的开发者 🧠 AI 与推理 记忆管理、浏览器自动化、深度思考 复杂任务场景 🛠️ DevOps 容器管理、Git 操作、云服务 DevOps/SRE 工程师 🔧 开发者工具 文档查询、自动化测试、代码执行 全栈开发者
MCP Server 生态
├── 📁 文件与数据
│ ├── Filesystem(读写本地文件)
│ ├── Postgres(数据库查询)
│ ├── SQLite(本地数据库)
│ └── Google Drive(云文档操作)
├── 🌐 网络与 API
│ ├── Fetch(HTTP 请求)
│ ├── Brave Search(网络搜索)
│ ├── GitHub(Issue/PR/仓库)
│ └── Slack(消息与频道)
├── 🧠 AI 与推理
│ ├── Memory(跨会话记忆)
│ ├── Puppeteer(浏览器自动化)
│ └── Sequential Thinking(多步推理)
├── 🛠️ DevOps
│ ├── Docker(容器管理)
│ ├── Git(版本控制)
│ └── Kubernetes(K8s 集群管理)
└── 🔧 开发者工具
├── Context7(实时文档查询)
├── Playwright(E2E 测试)
└── Code Execution(代码执行)
2.2 每类必装推荐
📁 文件与数据 Server 一句话 安装 Filesystem 读写本地文件系统,AI 直接操作项目文件 npx @modelcontextprotocol/server-filesystem /pathPostgres 数据库直连查询,自动发现表结构 npx @modelcontextprotocol/server-postgres <conn>SQLite 轻量数据库操作,本地开发神器 npx @modelcontextprotocol/server-sqlite db.sqliteGoogle Drive 读写云端文档和表格 npx @modelcontextprotocol/server-gdrive
🌐 网络与 API Server 一句话 安装 Fetch 让 AI 发起 HTTP 请求,抓取网页或调 API 内置于 Claude Code Brave Search 网络搜索,AI 联机获取最新信息 npx @modelcontextprotocol/server-brave-searchGitHub 管理 Issue、PR、仓库操作 npx @modelcontextprotocol/server-githubSlack 发送消息、读取频道 npx @modelcontextprotocol/server-slack
🧠 AI 与推理 Server 一句话 安装 Memory 跨会话持久化记忆,AI 拥有「长期记忆」 npx @modelcontextprotocol/server-memoryPuppeteer 浏览器自动化,AI 操控网页 npx @modelcontextprotocol/server-puppeteerSequential Thinking 结构化多步推理,复杂问题分解 npx @modelcontextprotocol/server-sequential-thinking
🛠️ DevOps Server 一句话 安装 Docker 容器管理,AI 操作 Docker npx @modelcontextprotocol/server-dockerGit 版本控制操作 npx @modelcontextprotocol/server-gitKubernetes K8s 集群管理 npx @modelcontextprotocol/server-kubernetes
🔧 开发者工具 Server 一句话 安装 Context7 实时查询最新库/框架文档,避免 AI 用过时 API npx @modelcontextprotocol/server-context7Playwright 端到端浏览器测试自动化(微软官方维护,~34K Stars) npx @modelcontextprotocol/server-playwrightMarkItDown 微软出品,将 PPTX/HTML/PDF 等转为 Markdown(~148K Stars) pip install markitdown
2.3 如何评估一个 MCP Server 的质量 并不是所有 MCP Server 都值得安装。2026 年初一项学术审计(Stony Brook / Georgia Tech,201 个 Server)发现:热门程度(Star 数)与质量没有正相关 ——最流行的 Server(如 Context7、Chrome DevTools)在 Schema 设计和文档质量上得分反而不如一些小型但专注的 Server(如 PostgreSQL MCP)。另一项独立扫描(mcp-scan 项目,2026.03)显示,52% 的远程 MCP 端点实际已不可用 ——要么 TLS 证书过期,要么直接宕机无响应。
维护活跃度 :最近 3 个月是否有提交?Issue 响应速度如何?
文档质量 :README 是否清晰说明安装步骤和使用场景?
安全风险 :该 Server 需要哪些权限?操作是否可逆?有没有沙箱?
安装复杂度 :一条命令搞定还是需要 API Key + 多步配置?
安装前先问自己:这个 Server 失败时,最坏的结果是什么? 如果答案是「删掉我的生产数据库」,那么务必先加一层安全保护。
3. MCP 协议技术骨架
本章面向想深入理解协议原理的读者。如果你只关心「怎么用」,可以跳到第 4 章。
3.1 三层架构 层 协议/格式 职责 语义层 MCP Spec 定义 Tools/Resources/Prompts 的语义和生命周期 消息层 JSON-RPC 2.0 请求/响应/通知的格式化与路由 传输层 stdio 或 Streamable HTTP 消息在进程间/网络间的可靠传输
这个设计的优雅之处在于:每层独立演进。传输层从 stdio 扩展到 HTTP+SSE,再到最新的 Streamable HTTP(2025.11 引入,2026.07 即将随新 Spec 稳定),语义层和消息层不需要任何修改。这就是分层架构的威力。
3.2 两种传输模式 MCP 支持两种主要传输方式,适用于不同的部署场景。
stdio(标准输入/输出) [Claude Code] ---stdin---> [MCP Server 进程]
<--stdout---
原理 :MCP Server 作为子进程运行,通过标准输入/输出流传递 JSON-RPC 消息
优点 :零网络依赖、自动生命周期管理、天然进程隔离
缺点 :仅限本机、Host 退出时 Server 也终止
适用 :本地开发工具(Filesystem、SQLite、Git 等)
Streamable HTTP(推荐用于远程部署) [Claude Code] ---HTTP POST---> [远程 MCP Server]
<---SSE/流式响应---
原理 :单一 HTTP 端点同时处理请求和服务器推送,无需 sticky session
优点 :支持远程部署、多客户端共享同一 Server、兼容 CDN 和负载均衡、零状态核
缺点 :需要网络、需要额外认证、部署复杂度更高
适用 :团队共享服务(Jira、Slack、内部 API 网关等)
替代了旧版 HTTP+SSE :在 2025 年 11 月 Spec 之后,Streamable HTTP 成为推荐方式,旧版 HTTP+SSE(需要两个端点 + Session ID)已逐步退出
初始化握手 :Host 通过 stdin 发送 initialize 请求(含协议版本和客户端能力),Server 通过 stdout 返回支持的能力列表
发现工具 :Host 发送 tools/list 请求,Server 返回所有可用工具的列表及 JSON Schema 参数定义
LLM 决策 :AI 根据用户指令和上下文,自主决定调用哪个工具、传入哪些参数
调用工具 :Host 发送 tools/call 请求(含工具名和参数),Server 执行操作并通过 stdout 返回结果
进程退出 :Host 关闭时,stdio 子进程自动终止,生命周期由 Host 全程管理
3.3 消息格式详解 MCP 使用 JSON-RPC 2.0 作为消息格式。下面看一个完整的工具调用流程:
第一步:初始化握手 // 客户端 → Server
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {
"tools": {},
"resources": {}
},
"clientInfo": {
"name": "claude-code",
"version": "2.0.0"
}
}
}
// Server → 客户端
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2025-11-25",
"capabilities": {
"tools": { "listChanged": true }
},
"serverInfo": {
"name": "github-mcp-server",
"version": "1.3.0"
}
}
}
第二步:发现可用工具 // 客户端 → Server
{ "jsonrpc": "2.0", "id": 2, "method": "tools/list", "params": {} }
// Server → 客户端
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"tools": [
{
"name": "github_create_issue",
"description": "在指定仓库创建 Issue",
"inputSchema": {
"type": "object",
"properties": {
"repo": { "type": "string", "description": "仓库名,如 owner/repo" },
"title": { "type": "string", "description": "Issue 标题" },
"body": { "type": "string", "description": "Issue 正文" }
},
"required": ["repo", "title"]
}
}
]
}
}
第三步:调用工具 // 客户端 → Server
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "github_create_issue",
"arguments": {
"repo": "myorg/myrepo",
"title": "修复登录页样式异常",
"body": "在 Safari 下登录按钮错位,详见截图"
}
}
}
// Server → 客户端
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"content": [
{
"type": "text",
"text": "Issue #42 已创建:https://github.com/myorg/myrepo/issues/42"
}
],
"isError": false
}
}
id 字段用于匹配请求和响应,支持并发调用
inputSchema 使用 JSON Schema 描述参数,LLM 据此生成符合规范的参数——Schema 写得越好,AI 调用越准确
isError: true 表示工具执行失败,但协议层通信成功(注意:工具失败≠协议失败)
标准 JSON-RPC 错误码:-32700(解析错误)、-32601(方法不存在)、-32602(参数无效)
2026.07 Spec 即将带来的变化
无状态协议核心 :不再需要 sticky session,任何服务器实例处理任何请求
Mcp-Method 和 Mcp-Name 头 :负载均衡器可以不解包 JSON 就能路由请求
工具列表缓存 :客户端可以根据 Server 返回的 ttlMs 缓存 tools/list 结果
3.4 安全模型 MCP 的安全模型是当前整个生态中最受关注也最具争议的话题。
默认行为:无沙箱 ⚠️ 这是你需要记住的最重要的事实:MCP Server 默认以当前用户权限运行,没有任何沙箱保护。
读写你整个文件系统
执行任意的 Shell 命令
访问你所有的环境变量(包括 API Key)
2026 年 1 月,Anthropic 的 Git Server 就出现了三个 CVE;随后在 mcp-remote 中又发现了一个严重的 RCE 漏洞。这些事件提醒我们:MCP 的安全模型目前还不够成熟。
现有的保护机制 机制 描述 局限 工具级 allow/deny 显式允许或拒绝特定工具 粒度粗,手动维护 用户确认 执行敏感操作前弹窗确认 确认疲劳导致用户习惯性点「允许」 进程隔离 stdio 模式下 Server 是独立进程 仅限进程级,无系统级沙箱
OAuth 2.1 授权(已于 2025.06 Spec 引入) MCP 从 2025 年 6 月 Spec 开始采用 OAuth 2.1 作为认证标准。MCP Server 充当 OAuth Resource Server,通过 .well-known/mcp-server-metadata.json 发现授权服务器。关键特性:
Client Credentials 流程 :Server-to-Server 认证
动态客户端注册 :基于 URL 的自动注册(SEP-991)
OIDC Discovery :标准化授权服务器发现
Resource Indicators (RFC 8707):限制 Token 的作用范围
但 OAuth 2.1 目前主要解决的是「认证」问题——即这个 Server 有权访问什么。更根本的「运行时沙箱」问题——即 Server 能做什么——仍然是开放的社区讨论。
只安装你了解其来源的 Server
优先选择只读工具(查询比写入安全)
敏感操作要求 AI 先说明它要做什么,你再确认执行
不要在共享/不可信的环境中使用 MCP Server
4. Claude Code / Cursor / VS Code MCP 横向对比
本章帮助你在三大主流 AI 编码工具中,选择最适合 MCP 工作流的那个。
4.1 对比总览 维度 Claude Code Cursor VS Code MCP 支持方式 原生(第一公民) 原生(Agent 集成) 内置(v1.99+)+ 扩展 配置文件 .claude/.mcp.json.cursor/mcp.jsonsettings.json 或扩展配置传输模式 stdio + Streamable HTTP stdio + HTTP+SSE(尚未跟进 Streamable) stdio + HTTP+SSE(尚未跟进 Streamable) 热加载 ✅ 修改即生效 ✅ 需重载窗口 ⚠️ 因配置方式而异 mcp add 交互式添加✅ ❌ ❌ MCP 工具自动调用 ✅ ✅ Agent 模式 ✅ Copilot Agent 模式 多 Server 编排 ✅ 项目级隔离 ✅ 项目级隔离 ✅ 通过 settings 调试体验 claude -d mcp + Inspector日志面板(DevTools) 扩展日志 autoApprove 白名单✅ ✅ ⚠️ 部分支持
4.2 Claude Code:MCP 的原生家园 Claude Code 是目前 MCP 实现最完整、体验最流畅的客户端——毕竟是 Anthropic 的亲儿子,MCP 是 Claude Code 的「一等公民」。
配置:一条命令搞定 # 添加 stdio 类型的 MCP Server(本地进程)
claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=$GITHUB_TOKEN -- npx -y @modelcontextprotocol/server-github
# 添加 HTTP 类型的 MCP Server(远程服务)
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp
# 添加 stdio Server 并设置环境变量
claude mcp add my-server -e API_KEY=xxx -- npx my-mcp-server
# 查看已配置的 MCP Server
claude mcp list
# 删除某个 Server
claude mcp remove github
// .claude/.mcp.json
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"],
"autoApprove": ["read_text_file", "list_directory", "search_files"]
}
}
}
独有特性 Claude Code 的 Skills 系统可以和 MCP 工具联动。例如定义一个 deploy skill,它内部自动调用 Docker MCP Server 的容器重启工具、Git MCP 的 Push 工具——一条 /deploy 指令串起多个 MCP Server。
{
"filesystem": {
"autoApprove": [
"read_text_file",
"list_directory",
"search_files"
]
}
}
--mcp-debug 已废弃,现在统一用 --debug(简写 -d)。可以过滤只看 MCP 日志:
# 只看 MCP 相关日志
claude -d mcp
# 看所有调试输出(包括 MCP、API 等)
claude -d
# 组合过滤:看 mcp 和 api,排除 statsig
claude -d mcp,api,\!statsig
# 写入文件
claude --debug-file /tmp/claude-debug.log
4. 项目级隔离 :.claude/.mcp.json 中的配置只影响当前项目,不同项目可以有完全不同的 MCP Server 集合。微服务项目中尤其有用——避免 AI 混淆不同服务的上下文。
一个小坑 修改 .mcp.json 后需要重启 Claude Code 才会生效。如果你在对话中动态添加了 Server,记得 Ctrl+C 退出重新启动。
4.3 Cursor:Agent 模式下的 MCP 自动调用 Cursor 从 0.45 版本开始原生支持 MCP,到 2026 年 1 月更新后加入了 CLI 命令支持(/mcp enable、/mcp disable 等)。
配置 // .cursor/mcp.json(项目级)
// ~/.cursor/mcp.json(全局)
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
},
"disabled": false,
"autoApprove": []
}
}
}
也可以在不写 JSON 的情况下通过 Settings → Cursor Settings → MCP 面板用 UI 添加。
与 Claude Code 的关键差异 Cursor 的 MCP 工具在 Chat 模式 下需要手动触发,但在 Agent 模式 下可以自动调用——Agent 自主决定何时使用哪个 MCP 工具来完成任务。这是 Cursor MCP 体验的核心亮点。配合 Auto-Run 模式(Settings → Features → Auto-Run),Agent 甚至可以跳过工具调用确认。
新增 Server 需要手动编辑 JSON 或用设置面板 UI。
Cursor 没有 claude -d mcp 这样的调试参数。排查 MCP 问题需要打开 Cursor 的开发者控制台(Cmd+Option+I 或 Ctrl+Shift+I),在 Console 面板中查找 MCP 相关日志。
修改 mcp.json 后需要用 Cmd+Shift+P → 「Developer: Reload Window」来重新加载。
适用场景
✅ 已在用 Cursor 的主力开发者,想在 Agent 模式下享受自动工具调用
❌ 重度依赖 MCP、需要精细调试 Server 的开发者
4.4 VS Code:巨人的转身 VS Code 在 MCP 上的步伐比前两者慢,但 2026 年发生了关键变化。
2026 年的里程碑 时间 事件 2026.01 VS Code v1.99 原生支持 MCP 配置(mcp.servers 设置) 2026.03 VS Code v1.110 引入 Agent Hooks,与 Claude Code 的 Hook 体系对齐 2026.04 Copilot Chat 在 Agent 模式下原生支持 MCP 工具调用
原生配置方式(v1.99+) // settings.json
{
"mcp.servers": {
"my-server": {
"command": "node",
"args": ["path/to/server.js"],
"cwd": "${workspaceFolder}"
}
},
"github.copilot.advanced": {
"mcp.enabled": true
}
}
也可以通过 Cmd+Shift+P → MCP: Add Server 用 UI 添加。
扩展选择 扩展 MCP 支持 特点 GitHub Copilot Chat ✅ 原生(v1.99+) Agent 模式自动调用,15M+ 用户 Continue ✅ 成熟 开源、自带模型、完整 MCP 支持 Cline ✅ 活跃 MCP 支持好,开发迭代快
VS Code 的优势在于:它是 75.9% 开发者的主力编辑器 。不需要切换工具就能获得 MCP 能力,这对很多人来说是最重要的选型因素。
4.5 综合评分 评分维度 Claude Code Cursor VS Code MCP 易用性 ★★★★★ ★★★★☆ ★★★☆☆ 调试体验 ★★★★★ ★★★☆☆ ★★☆☆☆ MCP 功能完整性 ★★★★★ ★★★★☆ ★★★☆☆ 安全控制粒度 ★★★★☆ ★★★★☆ ★★★☆☆ 编辑器生态整合 ★★★★☆ ★★★★★ ★★★★★ 零摩擦上手 ★★★★☆ ★★★★☆ ★★★★★
4.6 场景推荐 你的情况 推荐 理由 MCP 重度用户/开发自己的 MCP Server Claude Code claude -d mcp 和 autoApprove 无可替代主要在 Agent 模式下编码 Cursor Agent + MCP 自动调用是天作之合 因项目/团队原因不能切换编辑器 VS Code 原生 MCP 已可用,不需要迁移 组合使用 Cursor + Claude Code Cursor 写代码 + Claude Code 做复杂 MCP 调试任务
5. 从零构建 MCP Server
本章带你完整走通开发一个 MCP Server 的全流程。示例项目:天气查询服务。
5.1 选型:TypeScript SDK vs Python SDK 维度 TypeScript SDK Python SDK 包名 @modelcontextprotocol/sdkmcp(或 fastmcp)安装 npm install @modelcontextprotocol/sdk zodpip install mcp 或 pip install fastmcp生态 Node.js 生态,npm 发布方便,~9,700 万月下载 Python 生态,适合数据/ML 场景 类型安全 原生 TypeScript,编译期保障 运行时 Pydantic 校验 推荐场景 Web/全栈开发者 数据工程师/ML 工程师 当前版本 v1.29.0(稳定)/ v2 pre-alpha 稳定
选哪个取决于你更熟悉哪个生态。本文给出两个版本的完整实现。
5.2 示例项目:天气查询 MCP Server 功能 :让 AI 能够查询指定城市的当前天气和天气预报。
get_weather(city) → 当前天气(温度、湿度、天气状况)
get_forecast(city, days) → 未来 N 天预报
数据源 :Open-Meteo 免费 API(无需注册、无需 API Key、开源)
weather-mcp-server/
├── package.json # TS 版本
├── tsconfig.json # TS 版本
├── src/
│ └── index.ts # TS 版本入口
├── requirements.txt # Python 版本
├── server.py # Python 版本
└── README.md
5.3 TypeScript 实现
初始化 mkdir weather-mcp-server && cd weather-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node tsx
完整代码:src/index.ts import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
// 天气代码 → 中文描述(Open-Meteo 免费 API,无需 API Key)
const WEATHER_CODES: Record<number, string> = {
0: "晴朗", 1: "少云", 2: "多云", 3: "阴天",
45: "雾", 48: "冻雾",
51: "小毛毛雨", 53: "毛毛雨", 55: "大毛毛雨",
61: "小雨", 63: "中雨", 65: "大雨",
71: "小雪", 73: "中雪", 75: "大雪",
80: "阵雨", 81: "中等阵雨", 82: "大阵雨",
95: "雷暴", 96: "雷暴+小冰雹", 99: "雷暴+大冰雹",
};
// 创建 MCP Server 实例
const server = new McpServer({
name: "weather-mcp-server",
version: "1.0.0",
});
// 工具 1:查询当前天气
server.tool(
"get_weather",
"查询指定城市的当前天气,返回温度、湿度和天气描述",
{ city: z.string().describe("城市名称,如 '北京' 或 'Tokyo'") },
async ({ city }) => {
try {
// 地理编码:城市名 → 坐标
const geoUrl = `https://geocoding-api.open-meteo.com/v1/search?name=${encodeURIComponent(city)}&count=1&language=zh`;
const geoRes = await fetch(geoUrl);
const geoData = await geoRes.json();
if (!geoData.results?.length) {
return {
content: [{ type: "text", text: `未找到城市:${city}` }],
isError: true,
};
}
const { name, country, latitude, longitude } = geoData.results[0];
// 获取当前天气
const weatherUrl = `https://api.open-meteo.com/v1/forecast?latitude=${latitude}&longitude=${longitude}¤t=temperature_2m,relative_humidity_2m,wind_speed_10m,weather_code`;
const weatherRes = await fetch(weatherUrl);
const weatherData = await weatherRes.json();
const current = weatherData.current;
const weatherDesc = WEATHER_CODES[current.weather_code] ?? `代码${current.weather_code}`;
return {
content: [{
type: "text",
text: `${name}(${country})当前天气:
🌡️ 温度:${current.temperature_2m}°C
💧 湿度:${current.relative_humidity_2m}%
☁️ 天气:${weatherDesc}
🌬️ 风速:${current.wind_speed_10m} km/h`,
}],
};
} catch (err: any) {
return {
content: [{ type: "text", text: `查询失败:${err.message}` }],
isError: true,
};
}
}
);
// 工具 2:查询天气预报
server.tool(
"get_forecast",
"查询指定城市未来几天的天气预报",
{
city: z.string().describe("城市名称"),
days: z.number().min(1).max(7).default(3).describe("预报天数,范围 1-7"),
},
async ({ city, days }) => {
try {
const geoUrl = `https://geocoding-api.open-meteo.com/v1/search?name=${encodeURIComponent(city)}&count=1&language=zh`;
const geoRes = await fetch(geoUrl);
const geoData = await geoRes.json();
if (!geoData.results?.length) {
return {
content: [{ type: "text", text: `未找到城市:${city}` }],
isError: true,
};
}
const { name, country, latitude, longitude } = geoData.results[0];
// 获取天气预报
const forecastUrl = `https://api.open-meteo.com/v1/forecast?latitude=${latitude}&longitude=${longitude}&daily=temperature_2m_max,temperature_2m_min,weather_code&forecast_days=${days}&timezone=auto`;
const forecastRes = await fetch(forecastUrl);
const forecastData = await forecastRes.json();
const daily = forecastData.daily.time
.map((date: string, i: number) => {
const code = forecastData.daily.weather_code[i];
const desc = WEATHER_CODES[code] ?? `代码${code}`;
return `📅 ${date}: ${forecastData.daily.temperature_2m_min[i]}°C ~ ${forecastData.daily.temperature_2m_max[i]}°C, ${desc}`;
})
.join("\n");
return {
content: [{ type: "text", text: `${name}(${country})未来 ${days} 天预报:\n${daily}` }],
};
} catch (err: any) {
return {
content: [{ type: "text", text: `查询失败:${err.message}` }],
isError: true,
};
}
}
);
// 启动 Server(stdio 传输)
async function main() {
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("✅ Weather MCP Server 已启动(数据源:Open-Meteo 免费 API)");
}
main().catch(console.error);
配置到 Claude Code // .claude/.mcp.json
{
"mcpServers": {
"weather": {
"command": "npx",
"args": ["tsx", "/Users/me/weather-mcp-server/src/index.ts"]
}
}
}
注意:Open-Meteo 是免费 API,不需要 API Key,所以 env 字段可以省略。这也是选它做示例的重要原因——读者不需要先注册任何服务就能跑起来。
配置完成后重启 Claude Code,输入「帮我查一下北京今天的天气」——AI 会自动调用你刚写的 get_weather 工具,获取实时天气数据并组织成自然语言回复。
5.4 Python 实现 mkdir weather-mcp-server && cd weather-mcp-server
python -m venv venv && source venv/bin/activate
pip install mcp httpx
完整代码:server.py import httpx
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import TextContent
# 天气代码 → 中文描述(Open-Meteo 免费 API,无需 API Key)
WEATHER_CODES = {
0: "晴朗", 1: "少云", 2: "多云", 3: "阴天",
45: "雾", 48: "冻雾",
51: "小毛毛雨", 53: "毛毛雨", 55: "大毛毛雨",
61: "小雨", 63: "中雨", 65: "大雨",
71: "小雪", 73: "中雪", 75: "大雪",
80: "阵雨", 81: "中等阵雨", 82: "大阵雨",
95: "雷暴", 96: "雷暴+小冰雹", 99: "雷暴+大冰雹",
}
server = Server("weather-mcp-server")
@server.tool()
async def get_weather(city: str) -> list[TextContent]:
"""查询指定城市的当前天气,返回温度、湿度和天气描述"""
async with httpx.AsyncClient() as client:
# 地理编码
geo_resp = await client.get(
"https://geocoding-api.open-meteo.com/v1/search",
params={"name": city, "count": 1, "language": "zh"}
)
geo_data = geo_resp.json()
if not geo_data.get("results"):
return [TextContent(type="text", text=f"未找到城市:{city}")]
r = geo_data["results"][0]
name, country = r["name"], r.get("country", "")
lat, lon = r["latitude"], r["longitude"]
# 获取当前天气
weather_resp = await client.get(
"https://api.open-meteo.com/v1/forecast",
params={
"latitude": lat, "longitude": lon,
"current": "temperature_2m,relative_humidity_2m,wind_speed_10m,weather_code"
}
)
w = weather_resp.json()["current"]
desc = WEATHER_CODES.get(w["weather_code"], f"代码{w['weather_code']}")
text = (
f"{name}({country})当前天气:\n"
f"🌡️ 温度:{w['temperature_2m']}°C\n"
f"💧 湿度:{w['relative_humidity_2m']}%\n"
f"☁️ 天气:{desc}\n"
f"🌬️ 风速:{w['wind_speed_10m']} km/h"
)
return [TextContent(type="text", text=text)]
@server.tool()
async def get_forecast(city: str, days: int = 3) -> list[TextContent]:
"""查询指定城市未来几天的天气预报,days 范围 1-7"""
async with httpx.AsyncClient() as client:
geo_resp = await client.get(
"https://geocoding-api.open-meteo.com/v1/search",
params={"name": city, "count": 1, "language": "zh"}
)
geo_data = geo_resp.json()
if not geo_data.get("results"):
return [TextContent(type="text", text=f"未找到城市:{city}")]
r = geo_data["results"][0]
name, country = r["name"], r.get("country", "")
lat, lon = r["latitude"], r["longitude"]
fc_resp = await client.get(
"https://api.open-meteo.com/v1/forecast",
params={
"latitude": lat, "longitude": lon,
"daily": "temperature_2m_max,temperature_2m_min,weather_code",
"forecast_days": days, "timezone": "auto"
}
)
fc = fc_resp.json()["daily"]
daily = [
f"📅 {fc['time'][i]}: {fc['temperature_2m_min'][i]}°C ~ {fc['temperature_2m_max'][i]}°C, "
f"{WEATHER_CODES.get(fc['weather_code'][i], f\"代码{fc['weather_code'][i]}\")}"
for i in range(len(fc["time"]))
]
return [TextContent(type="text", text=f"{name}({country})未来 {days} 天预报:\n" + "\n".join(daily))]
async def main():
async with stdio_server() as (read_stream, write_stream):
await server.run(
read_stream, write_stream, server.create_initialization_options()
)
if __name__ == "__main__":
import asyncio
asyncio.run(main())
Python 版配置 {
"mcpServers": {
"weather": {
"command": "python",
"args": ["/Users/me/weather-mcp-server/server.py"]
}
}
}
与 TS 版一样,不需要 API Key——Open-Meteo 完全免费开源。
TS vs Python:选哪个? 两种实现功能完全一致,代码量也相近(~80 行)。选哪个取决于你更熟悉哪个生态。一个实用建议:如果你的团队技术栈是 Node.js,用 TS 版本,省去在 CI 中安装 Python 运行时的心智负担;反之亦然。
5.5 本地调试:MCP Inspector 开发 MCP Server 的核心调试工具是 MCP Inspector ,一个基于 Web 的交互式调试面板:
npx @modelcontextprotocol/inspector tsx src/index.ts
Tools :列出所有注册的工具,手动传入参数测试调用
Resources :浏览 Server 暴露的所有资源
Messages :查看完整的 JSON-RPC 收发记录——这是调试的杀手锏
如果工具调用返回 isError: true,Messages 面板能帮你定位是参数格式问题还是 API 调用失败。
5.6 发布到社区 开发完成后,让你的 MCP Server 被别人发现和使用:
发布到 npm / PyPI
npm publish # TypeScript 版本
# 或
pip install twine && twine upload dist/* # Python 版本
写好 README :必须包含安装命令、配置 JSON 示例、工具列表和参数说明
提交到社区列表 :在 modelcontextprotocol/servers 仓库提 PR
打标签 :GitHub 仓库添加 mcp-server 主题标签,方便被搜索
5.7 开发中常见坑点 1. console.log 会阻塞 stdio 通信
这是最高频也最隐蔽的坑。stdio 传输模式下,stdout 是 MCP 协议的唯一通信通道——你在 Server 代码中写的任何 console.log() 都会污染协议消息流,导致 JSON-RPC 解析失败,Host 端报 MCP error -32000: Connection closed。
✅ 正确做法:调试输出统一用 console.error()(写入 stderr,不干扰 stdout)
❌ 错误做法:console.log("收到请求") → stdout 被写入非法 JSON → 协议中断
LLM 只能通过你写的 description 字符串来判断「这个工具能干什么」。描述模糊 = AI 用错或不用。
❌ 差:description: "查询天气"
✅ 好:description: "查询指定城市的当前天气,返回温度(°C)、湿度(%)、天气状况和风速。支持中英文城市名,数据源为 Open-Meteo 免费 API"
关键技巧:描述里直接告诉 AI 什么时候该用这个工具、参数该填什么 。
tools/call 返回 isError: true 不会断开连接,但未捕获的异常会直接杀死 stdio 子进程 ,使整个 Server 不可用。
// ❌ 抛异常 → 进程退出
if (!data) throw new Error("No data");
// ✅ 返回 isError → 进程存活
if (!data) {
return { content: [{ type: "text", text: "数据为空" }], isError: true };
}
inputSchema 中如果不设 required 字段和具体约束,AI 可能传入意料之外的参数组合。Zod(TS)和 Pydantic(Python)的类型定义会直接影响 AI 的参数生成质量——Schema 描述得越精确,AI 的调用越准确。
Claude Code 可以同时挂载多个 MCP Server,但不同 Server 的工具名是全局可见的 。如果两个 Server 都注册了 read_file 工具,AI 可能调用到错误的那个。建议在工具名中加入命名空间前缀,如 weather_get_forecast 而非 get_forecast。
6. 竞争格局与标准化进展
6.1 AI 工具集成方案光谱 AI 如何连接外部工具?过去三年经历了从分裂到统一的过程:
厂商锁定 ←————————————————————————————→ 自构方案
OpenAI MCP LangChain/
Plugins (中立协议) LlamaIndex
(已死)
左端:厂商锁定方案(已失败) OpenAI Plugins (2023.03 发布 → 2024 年 3 月宣布停止、4 月正式移除)是最早的尝试。它让 ChatGPT 能调用第三方 API,但致命缺陷是:每个 Plugin 只能用于 ChatGPT,换一个 LLM 就要全部重新实现。
GPT Actions 作为 Plugin 的继任者,改进了安全性,但本质上仍是 OpenAI 专属方案——而且在 2024 年初也迅速被弃用。
ChatGPT Apps (2025.10 DevDay 发布)是 OpenAI 的最新方案——而且这次它建立在 MCP 之上。OpenAI 的 Agent SDK(2025.03)也原生支持 MCP。这说明连 OpenAI 都承认:专属协议的路走不通。
Google Gemini Functions 和 Anthropic Tool Use 也有类似问题——它们是 API 特性,不是互操作标准。
右端:自构方案(灵活但不可移植) LangChain、LlamaIndex 等框架让开发者自己封装工具调用逻辑。灵活度最高,但每种工具的集成代码不可移植——你为 LangChain 写的 GitHub 工具,没法在 LlamaIndex 里复用。
中端:MCP 的位置 MCP 不绑定任何厂商,一次实现,到处运行。这就是为什么 Cursor(多模型)、VS Code(微软)、ChatGPT(OpenAI)都在用——它不是 Anthropic 的专属生态。
6.2 MCP 为什么赢了 MCP 不绑定任何 LLM 厂商。Server 开发者只写一次,所有客户端都能用。这是标准的网络效应飞轮——Server 越多,客户端越有吸引力;客户端越多,Server 开发者越有动力贡献。
JSON-RPC 2.0 + stdio,任何一个做过 Web 开发的工程师都能在 30 分钟内理解全部原理。写一个 MCP Server 的最小实现不到 50 行代码。对比 OAuth + OpenAPI + Webhook 的 Plugin 方案,MCP 的门槛低了一个数量级。
Anthropic 没有试图自己造所有 Server。官方只维护核心基础类,其余品类由社区填充。到 2026 年中,社区已经贡献了从 AWS 管理到 Notion 同步再到论文检索的各种 Server。
6.3 标准化进展 MCP 正在从 Anthropic 的内部规范走向正式的开放标准:
里程碑 状态 影响 2025.11 Streamable HTTP ✅ 已稳定 替代旧版 SSE,单端点、无状态、CDN 友好 2025.06 OAuth 2.1 ✅ 已稳定 细粒度认证,Client Credentials + DCR Resource Templates ✅ 已稳定 参数化资源 URI,如 weather://current/{city} 2026.07 新 Spec(2026-07-28 正式发布) ⚠️ RC 阶段(发布日期已确认) 无状态核心、MCP Apps(Server 端 UI)、Tasks 扩展、Mcp-Method 头路由 Linux Foundation 治理 ✅ 已完成 2025.12 捐赠给 Agentic AI Foundation,独立治理 MCP Server 认证计划 🔮 预期 2026 H2 Anthropic 推出「官方认证」徽章,安全审查 + 质量标记 MCP Registry(市场) 🔮 预期 2026 Q4 类似 VS Code 扩展市场的 Server 发现与安装平台 IETF 提交 🔮 预期 2027 从 Anthropic 规范变为 IETF RFC 级别的互联网标准
6.4 争议与批评 最大的隐忧。详见 §3.4 安全模型 的完整分析。简言之:MCP Server 以宿主进程的全部权限运行,无沙箱隔离;社区呼吁 Docker/WASM 容器化沙箱但协议层尚未强制要求。2026 年 1 月 Anthropic 官方 Git Server 的三个 CVE 以及 mcp-remote 的 RCE 漏洞,证明这不仅是理论风险。
虽然 MCP 已捐赠给 Linux Foundation,但 Spec 的演进方向、SDK 的维护、官方 Server 的发布仍由 Anthropic 主导。这种「开放标准 + 单一主要贡献者」的模式和 Google 与 Kubernetes 的关系类似——有风险,但目前运行良好。
一个常见误解是把 Google 的 A2A(Agent-to-Agent Protocol)当成 MCP 的竞争对手。实际上它们解决的层次不同:
维度 MCP A2A 创建者 Anthropic(2024.11) Google(2025.04) 方向 垂直 — Agent ↔ 工具/数据水平 — Agent ↔ Agent核心问题 「我能用什么工具?」 「哪个 Agent 应该处理这个任务?」 协议 JSON-RPC 2.0 over stdio/HTTP JSON-RPC 2.0 + JSON-LD Agent Cards 治理 Linux Foundation Linux Foundation(2025.06 捐赠)
更合理的未来图景是:多个 Agent 通过 A2A 协作,每个 Agent 内部通过 MCP 调用工具。两者组合,而不是二选一。
7. 风险、限制与未来路线图
7.1 当前限制:诚实面对 MCP 作为一个 19 个月大的协议,还有很多不成熟的地方:
限制 具体表现 影响 无沙箱执行 Server 以当前用户全权限运行 恶意 Server = 全盘沦陷 多工具冲突 两个 Server 同时修改同一文件,无锁/无事务 数据竞争 流式响应不完整 长耗时工具调用缺少进度反馈 用户不知工具在「卡住」还是「在跑」 服务发现原始 必须手动配置 JSON,无自动发现 离「一次配置,到处可用」还很远 Server 状态管理 stdio 模式下进程随 Host 启动/退出 高频调用场景有启动开销 资源缓存缺失 同一 Resource 被反复请求时无缓存 浪费 API 配额和响应时间 质量参差不齐 52% 远程端点已死,Star 数与质量无关 选型成本高
7.2 未来 18 个月路线图预测 基于 Spec 草案进展(截至 2026 年 6 月,2026-07-28 为当前 RC 版本的既定发布日期)、社区讨论和行业趋势,以下按确定性由高到低排列:
时间窗口 里程碑 状态 2026.07-08 2026-07-28 Spec 正式发布、Streamable HTTP 最终稳定 ✅ 已确认(当前 RC 版既定发布日期) 2026.08-12 更多客户端原生集成、安全认证 Server 计划、MCP Registry Alpha ⚠️ 推进中 2027.01-04 安全沙箱标准化、OAuth 2.1 授权普及 ⚠️ 社区讨论 2027.03-06 多工具事务支持、IETF 草案提交、Agent-to-Agent MCP 桥接 🔮 早期规划 2027.07-09 MCP Registry 正式版、多模态 Resource 类型 🔮 远期目标 2027.09-12 WASM 沙箱运行时、MCP 与 A2A 深度融合 🔮 远期目标
短期(0-6 个月,2026 H2)
✅ 2026-07-28 Spec 正式发布 :无状态核心、Streamable HTTP 最终稳定、MCP Apps
⚠️ 更多客户端原生集成 :JetBrains IDE、Windsurf 等跟进原生 MCP 支持
⚠️ 安全认证 Server 计划 :Anthropic 推出「官方认证」徽章,经过安全审查的 Server 标记
🔮 MCP Registry Alpha :类似 VS Code 扩展市场的 Server 发现平台
中期(6-12 个月,2027 H1)
⚠️ 安全沙箱标准化 :Docker / WebAssembly 沙箱成为推荐运行方式,操作系统级隔离
⚠️ OAuth 2.1 授权全面普及 :细粒度权限控制成为主流,不再传全量 Token
🔮 多工具事务支持 :跨 Server 操作的原子性保障
🔮 IETF 草案提交 :MCP 正式进入互联网标准流程
长期(12-18 个月,2027 H2)
🔮 MCP Registry 正式上线 :mcp install weather 一键安装
🔮 多模态 Resource :支持图像、音频、视频资源的标准化暴露
🔮 WASM 沙箱运行时 :用 WebAssembly 实现跨语言的安全 Server 运行环境
🔮 MCP + A2A 深度融合 :两个协议在规范层面互操作
7.3 给不同读者的建议 先装 3 个核心 Server——Filesystem (文件操作)、Brave Search (网络搜索)、GitHub (Issue/PR 管理)。花 30 分钟感受 AI + 工具组合拳的威力。如果觉得没什么用,试试让 AI 帮你从 GitHub 上找 Issue、分析 Bug、然后创建 PR——这个端到端流程会让你体会到「AI 有了手和眼」是什么意思。
据调查,大多数 MCP 用户配置了 2-7 个 Server 。不要一开始就装 20 个——先从 3 个开始,用熟了再加。
搭建你的个人 MCP Server 矩阵。找出你日常工作中重复的 3-5 个操作(查数据库、搜日志、发通知、写周报),为每个配一个 MCP Server。到这一步,你会真正理解 MCP 为什么是「AI 的 USB-C 接口」。
现在是为社区贡献 MCP Server 的最佳窗口期。对照第 2 章的分类图谱,找一个还没有覆盖的缝隙,花一个周末写出来。生态系统还在早期,先行者优势巨大。Gartner 预测到 2026 年底 40% 的企业应用会包含 AI Agent——每个 Agent 背后都需要 MCP Server 连接数据和工具。
附录 A:MCP Server 速查表
A.1 推荐 Server 一览 Server 分类 功能 安装命令 需 Key Filesystem 📁 文件与数据 读写本地文件 npx @modelcontextprotocol/server-filesystem /path否 Postgres 📁 文件与数据 数据库查询 npx @modelcontextprotocol/server-postgres <url>否 SQLite 📁 文件与数据 本地数据库 npx @modelcontextprotocol/server-sqlite db.sqlite否 Google Drive 📁 文件与数据 云文档操作 npx @modelcontextprotocol/server-gdrive是 Fetch 🌐 网络与 API HTTP 请求 内置于 Claude Code 否 Brave Search 🌐 网络与 API 网络搜索 npx @modelcontextprotocol/server-brave-search是 GitHub 🌐 网络与 API Issue/PR/仓库 npx @modelcontextprotocol/server-github是 Slack 🌐 网络与 API 消息与频道 npx @modelcontextprotocol/server-slack是 Memory 🧠 AI 与推理 跨会话记忆 npx @modelcontextprotocol/server-memory否 Puppeteer 🧠 AI 与推理 浏览器自动化 npx @modelcontextprotocol/server-puppeteer否 Sequential Thinking 🧠 AI 与推理 多步推理 npx @modelcontextprotocol/server-sequential-thinking否 Docker 🛠️ DevOps 容器管理 npx @modelcontextprotocol/server-docker否 Git 🛠️ DevOps 版本控制 npx @modelcontextprotocol/server-git否 Context7 🔧 开发者工具 实时文档 npx @modelcontextprotocol/server-context7否 Playwright 🔧 开发者工具 E2E 测试 npx @modelcontextprotocol/server-playwright否 MarkItDown 🔧 开发者工具 文件转 Markdown pip install markitdown否
A.2 主流客户端 MCP 配置模板
Claude Code // .claude/.mcp.json(项目级,推荐)
{
"mcpServers": {
"server-name": {
"command": "npx",
"args": ["-y", "@scope/mcp-server-name"],
"env": { "API_KEY": "${ENV_VAR}" },
"autoApprove": ["safe_tool_name"]
}
}
}
Claude Desktop // macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
// Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"server-name": {
"command": "npx",
"args": ["-y", "@scope/mcp-server-name"]
}
}
}
Cursor // .cursor/mcp.json(项目级)或 ~/.cursor/mcp.json(全局)
{
"mcpServers": {
"server-name": {
"command": "npx",
"args": ["-y", "@scope/mcp-server-name"],
"env": { "API_KEY": "${ENV_VAR}" },
"disabled": false,
"autoApprove": []
}
}
}
VS Code(原生,v1.99+) // settings.json
{
"mcp.servers": {
"server-name": {
"command": "node",
"args": ["path/to/server.js"],
"cwd": "${workspaceFolder}"
}
},
"github.copilot.advanced": {
"mcp.enabled": true
}
}
VS Code(Continue 扩展) // ~/.continue/config.json
{
"experimental": {
"modelContextProtocolServers": [
{
"transport": {
"type": "stdio",
"command": "node",
"args": ["path/to/server/dist/index.js"]
}
}
]
}
}
A.3 调试工具速查 工具 用途 命令 MCP Inspector Web 交互式调试面板 npx @modelcontextprotocol/inspector <command>Claude Code -d mcp 查看原始 JSON-RPC 消息(--mcp-debug 已废弃) claude -d mcpCursor DevTools Console 面板 MCP 日志 Cmd+Option+I(macOS)/ Ctrl+Shift+I → Consolestderr 日志 Server 内部调试输出 console.error() 不会干扰 stdio 协议通信
A.4 学习资源
写在最后 :MCP 19 个月从零到 9,700 万月下载的轨迹,说明 AI 工具互操作不是一个「锦上添花」的需求,而是刚需。作为开发者,现在是最好的时机——生态还在早期,标准还在成型,你的每一个贡献都可能影响未来十年 AI 工具链的走向。
如果你从这篇文章学到了东西,欢迎在评论区讨论,或者直接去写一个 MCP Server 然后分享出来——这比任何评论都更有价值。