模型上下文協議：今天就开始构建你的第一个 MCP 服务器

**模型上下文协议（Model Context Protocol，简称 MCP）**是一项开放标准，为 AI 模型提供了一种连接外部工具、数据源和服务的通用方式。你无需为每种模型与工具的组合编写自定义集成代码，只需编写一个 MCP 服务器，所有兼容的模型即可使用它。Anthropic 于 2024 年底创建了 MCP，目前由 Linux Foundation 管理，OpenAI、Google 以及整个代理式 AI（Agentic AI）生态系统均已采用。以下是你理解、构建和部署 MCP 所需的一切知识。

MCP 概览

如果你想先快速了解概况，再深入阅读数千字的细节，请看这里。

现在让我们逐一解析这些内容，首先从 MCP 究竟是什么以及它为何必要开始。

什么是模型上下文协议？

模型上下文协议是一种基于 JSON-RPC 的开放协议，标准化了 AI 模型发现和与外部工具及数据交互的方式。你可以将其视为 AI 集成的 HTTP，一种任何模型和任何工具都能使用的通用语言。

你可能听过 USB-C 的类比，这在一定程度上很有用：在 USB-C 之前，每个设备都需要自己的线缆。MCP 对 AI 做了同样的事，但这个类比还低估了它。USB-C 仅传输数据和电力。而 MCP 传输工具定义、数据访问模式、可重用的提示词模板，甚至允许服务器向模型请求补全。这是一个比线缆隐喻更丰富的协议。

MCP 解决的 M x N 问题

如果没有 MCP，将 M 个模型连接到 N 个工具需要 M x N 个自定义集成。假设你支持 5 个大语言模型（Claude、GPT-4、Gemini、Llama、Mistral），并需要它们访问 10 个工具（GitHub、Postgres、Slack、Jira 等）。那就是 50 个 bespoke 集成层，每个都有各自的身份验证、错误处理和数据格式化。

有了 MCP，每个模型只需实现一次 MCP 客户端协议，每个工具只需实现一次 MCP 服务器。现在是 5 + 10 = 15 个实现，而不是 50 个。添加一个新模型？它立即就能与所有 10 个工具配合工作。添加一个新工具？所有 5 个模型都可以使用它。

MCP 简史

Anthropic 于 2024 年 11 月开源了 MCP，同时发布了 Python 和 TypeScript 的 SDK 以及 Claude Desktop 的连接器。采用速度很快。OpenAI 于 2025 年 3 月在 ChatGPT 中添加了 MCP 支持。Google 随后于 2025 年 4 月在 Gemini 中跟进。到 2025 年 12 月，Anthropic 将 MCP 捐赠给了 Linux Foundation 新成立的代理式 AI 基金会（AAIF），该基金会由 Block 和 OpenAI 联合创立，使 MCP 成为一个具有跨行业治理能力的供应商中立标准。

MCP 不是：

• 不是模型或 AI 框架（它是一个协议，类似 HTTP）
• 不是 LangChain 或 LlamaIndex 的替代品（那些是编排层；MCP 位于其下层）
• 不仅限于 Anthropic 或 Claude（设计上与模型无关）
• 不同于函数调用（更多细节见对比部分）

MCP 如何工作？架构深度解析

MCP 有三个角色，混淆它们是初学者最常见的错误。让我们明确区分它们。

Host、Client 和 Server 有什么区别？

举个具体例子：你要求 Claude Desktop 检查你未关闭的 GitHub Pull Request。Claude Desktop 是 Host。其内置的 MCP Client 打开与 GitHub MCP Server 的连接。服务器调用 GitHub API，获取你的 PR 列表，并将结果返回给客户端，客户端再将其交给模型。

单个 Host 可以运行多个 Client，每个连接到不同的 Server。这就是 Claude Desktop 如何同时访问 GitHub、你的 Postgres 数据库和 Slack 的原因——三个独立的 MCP 服务器，三个独立的客户端连接，一个 Host。

消息流如何运作（JSON-RPC 2.0）

所有 MCP 通信都使用 JSON-RPC 2.0，这是一种轻量级的请求/响应协议。以下是线路上 tools/list 交换的样子：

// Client request: "What tools do you have?"
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Server response: one tool available
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather for a city",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

模型读取这些工具定义，根据用户请求决定何时调用它们，然后客户端将带有适当参数的 tools/call 请求发送回服务器。

连接生命周期

每个 MCP 会话都遵循相同的生命周期：

1. 初始化（Initialize），客户端发送能力，服务器响应其自身能力
2. 能力协商（Capability negotiation），双方就支持的功能达成一致（工具、资源、提示词、采样）
3. 就绪（Ready），连接激活；请求双向流动
4. 请求/响应，tools/call、resources/read 等
5. 关闭（Shutdown），干净断开

这种握手确保了向前兼容性。如果服务器添加了新的原语，旧客户端会优雅地忽略它而不是崩溃。

MCP 原语：工具、资源、提示词和采样

MCP 定义了四种原语，理解谁控制每一种原语是设计良好 MCP 服务器的关键。

工具（模型控制）

工具是模型可以调用的函数。服务器通过名称、描述和 JSON Schema 输入定义来声明它们。模型读取这些定义，当用户请求需要时，模型决定调用工具。

// Client sends tools/call request
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Berlin" }
  }
}

如果你使用过 OpenAI 函数调用，工具会让你感到熟悉，但它们在每一个兼容 MCP 的模型中都是标准化的。

资源（应用程序控制）

资源是只读数据端点。与工具不同，模型不会自行决定获取资源，而是由宿主应用程序或用户显式地将资源附加到对话上下文中。可以将它们视为 GET 端点：postgres://mydb/users/schema、file://docs/api-reference.md。

资源支持通过 resources/subscribe 进行订阅，因此当数据更改时，客户端可以收到通知。

提示词（用户控制）

提示词是 MCP 服务器公开的可重用模板。code_review 提示词可能接受文件路径并生成结构化的审查请求。用户（或 Host UI）显式触发提示词，它们不会由模型自动调用。

采样（服务器发起），高级

这是大多数指南跳过的原语。采样允许服务器请求客户端使用 LLM 生成补全。这颠倒了通常的流程：不再是模型调用工具，而是工具调用模型。

为什么？为了代理循环。想象一个处理支持工单的 MCP 服务器。它读取工单（资源），使用 sampling/createMessage 要求模型生成摘要，然后使用该摘要通过工具路由工单。服务器利用模型的智能协调多步骤工作流。

采样受宿主应用程序限制，用户必须批准，且 Host 控制服务器可以请求的内容。这防止了失控循环并保持了人工监督。

构建你的第一个 MCP 服务器：Python 和 TypeScript 并排展示

理论够了。让我们构建一个暴露 get_weather 工具的工作型 MCP 服务器。我将同时展示 Python 和 TypeScript，以便你比较开发者体验并选择适合你项目的技术栈。

使用 FastMCP 的 Python

FastMCP 是官方的高级 Python SDK。它处理所有协议管道，让你专注于工具逻辑。

# Install FastMCP
pip install fastmcp

# weather_server.py
from fastmcp import FastMCP

mcp = FastMCP("Weather Server")

@mcp.tool()
def get_weather(city: str) -> str:
    """Get the current weather for a city."""
    # In production, call a real weather API here
    weather_data = {
        "Berlin": "Cloudy, 12°C",
        "Tokyo": "Sunny, 22°C",
        "New York": "Rainy, 8°C",
    }
    return weather_data.get(city, f"No data for {city}")

if __name__ == "__main__":
    mcp.run()

就这样——15 行代码。FastMCP 从 Python 类型提示和文档字符串中推断工具的输入模式。无需 JSON Schema 样板代码。

使用官方 SDK 的 TypeScript

TypeScript SDK (@modelcontextprotocol/sdk) 稍微更显式一些，但让你完全控制模式定义。

# Install the SDK and Zod for schema validation
npm install @modelcontextprotocol/sdk zod

// weather-server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "Weather Server",
  version: "1.0.0",
});

server.tool(
  "get_weather",
  "Get the current weather for a city",
  { city: z.string() },
  async ({ city }) => {
    const weatherData: Record<string, string> = {
      Berlin: "Cloudy, 12°C",
      Tokyo: "Sunny, 22°C",
      "New York": "Rainy, 8°C",
    };
    return {
      content: [
        { type: "text", text: weatherData[city] ?? `No data for ${city}` },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

TypeScript 版本使用 Zod 模式而不是类型提示，并返回结构化内容块。虽然更冗长，但类型安全性极佳。

连接到 Claude Desktop

要将任一服务器接入 Claude Desktop，请将其添加到你的 claude_desktop_config.json：

{
  "mcpServers": {
    "weather-python": {
      "command": "python",
      "args": ["weather_server.py"],
      "cwd": "/path/to/your/project"
    },
    "weather-typescript": {
      "command": "npx",
      "args": ["tsx", "weather-server.ts"],
      "cwd": "/path/to/your/project"
    }
  }
}

重启 Claude Desktop，两个天气服务器都会出现在工具列表中。询问“柏林的天气如何？”，模型会自动调用你的 get_weather 工具。

使用 MCP Inspector 测试

在将服务器连接到 Host 之前，请使用 MCP Inspector 独立测试它：

npx @modelcontextprotocol/inspector python weather_server.py

Inspector 打开一个浏览器 UI，你可以查看发现的工具、手动调用它们，并检查来回传输的 JSON-RPC 消息。它是 MCP 生态系统中最好的调试工具，尽早并经常使用它。

MCP 传输层：开发用 stdio，生产用 Streamable HTTP

MCP 消息需要在客户端和服务器之间传输。这就是传输层，选择合适的传输层很重要。

stdio 通过将 MCP 服务器生成为子进程并通过 stdin/stdout 进行通信来工作。这就是你在上面的教程中使用的，不需要端口、TLS 或身份验证。非常适合开发和单用户本地工具。

Streamable HTTP 是生产传输层，在 2025 规范更新中添加。客户端向服务器发送标准 HTTP POST 请求。服务器可以同步响应或为较长操作打开 SSE 流。它对无状态友好，可在负载均衡器后面工作，并支持标准 HTTP 身份验证。

如果你看到较旧的教程提到“HTTP+SSE”作为两种单独的传输层（一种用于发送，一种用于接收），那是已弃用的方法。Streamable HTTP 将两者合并为一个更清晰的机制。

决策很简单：本地开发时使用 stdio，为他人部署时切换到 streamable-http。

// Switching from stdio to Streamable HTTP in TypeScript
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";

const transport = new StreamableHTTPServerTransport({ port: 3001 });
await server.connect(transport);

MCP vs 函数调用 vs REST API，何时使用哪种

这是每次 MCP 讨论中都会出现的问题，所以让我们通过直接对比来解决它。

何时函数调用就够了

如果你的工具少于 5 个且只使用一个模型，函数调用更简单。 你在每次 API 调用中内联定义工具模式，模型返回函数名称和参数，你在应用程序代码中执行它们。无需运行服务器，无需学习协议。对于一个检查订单状态和查找常见问题解答的聊天机器人，函数调用完全没问题。

何时 MCP 变得值得

当出现以下情况时，MCP 的复杂性是值得的：

• 你支持多个 LLM，且不想为每个提供商重写工具定义
• 你需要工具发现，模型可以查询可用内容，而不是硬编码模式
• 你想要资源和提示词，而不仅仅是工具调用
• 你正在构建自主协调的 AI 代理，需要标准化的集成层
• 你的团队正在增长，不同的工程师构建不同的工具，MCP 让他们能够独立工作

结论：当你需要标准化、多模型工具访问时，MCP 胜出。对于简单的单模型用例，函数调用胜出。 REST API 仍然是不涉及 LLM 的传统服务间通信的正确选择。

2026 年的 MCP 生态系统：谁支持它以及有什么可用

MCP 在不到 18 个月内从 Anthropic 的副业项目变成了行业标准。以下是现状。

哪些 LLM 支持 MCP？

值得了解的流行 MCP 服务器

MCP 捐赠时的 Linux Foundation AAIF 公告 引用了 10,000+ 活跃服务器和每月 9700 万次 SDK 下载。生态系统不再是实验性的，而是生产级的。

MCP Apps 是 2026 年 1 月引入的新原语。它允许服务器提供在宿主应用程序内渲染的交互式 UI 组件。虽然仍处于早期阶段，但这标志着 MCP 从数据协议向完整代理-应用程序框架的演变。值得关注。

治理：从 Anthropic 到 Linux Foundation

MCP 由 Linux Foundation 旗下的 代理式 AI 基金会（AAIF） 管理，由 Anthropic、Block 和 OpenAI 联合创立。这对企业采用很重要：MCP 不绑定于单一供应商的路线图。2026 路线图 的重点是传输层演进、代理间通信（新的“Tasks”原语）、治理成熟度和企业就绪性。

对于构建生产级 AI 系统的团队，像 OpenClaw 这样的自主 AI 代理框架 已经与 MCP 服务器集成，赋予代理现实世界的能力。

MCP 安全性：OAuth 2.1、威胁和实用清单

安全性是 MCP 生态系统最需要加强的领域。数据描绘了一幅严峻的画面。

88% 的问题：为什么大多数 MCP 服务器不安全

Astrix Security 分析了 5,200+ 个开源 MCP 服务器实现，发现 88% 需要某种形式的凭据，但 53% 依赖于不安全的长期静态秘密，如硬编码在配置文件中的 API 密钥和个人访问令牌。只有 8.5% 实现了 OAuth。

这意味着野外绝大多数 MCP 服务器使用的身份验证相当于把家门钥匙胶带贴在正门上。

MCP 服务器的 OAuth 2.1

截至 2025 年 6 月的更新，MCP 规范要求所有基于 HTTP 的服务器使用 OAuth 2.1。流程如下：MCP 客户端启动与服务器的 OAuth 2.1 授权流程，获取范围受限的访问令牌，并在每个后续请求中包含它。PKCE（代码交换证明密钥）是所有客户端所必需的，没有例外。

如果你正在构建通过 Streamable HTTP 运行的 MCP 服务器，OAuth 2.1 不是可选的。它是规范强制要求的。

威胁模型：可能出什么问题

在任何 MCP 部署中，有四种威胁值得关注：

• 通过工具的提示词注入，恶意或被篡改的数据源返回旨在操纵模型的内容。如果工具获取网页且该页面包含隐藏指令，模型可能会执行它们。
• 混淆代理人攻击，模型以比用户意图更广泛的权限调用工具。如果 MCP 服务器拥有数据库的管理员访问权限，模型理论上可以删除表。
• 令牌集中风险，持有 GitHub、Slack 和生产数据库 API 密钥的 MCP 服务器是一个单一的高价值目标。攻破一个服务器，就攻破了它连接的所有内容。
• 不安全的传输，在没有 TLS 的情况下运行 HTTP MCP 服务器会以明文形式暴露每个请求，包括 OAuth 令牌和敏感数据。

生产级 MCP 的安全清单

1. 为任何通过 HTTP 暴露的服务器实施 OAuth 2.1。 配置文件中不要有静态 API 密钥。
2. 应用最小权限范围。 如果你的工具只读取数据，服务器的凭据应该是只读的。不要给报告工具写入权限。
3. 隔离凭据。 每个 MCP 服务器应有其自己的范围受限令牌。不要在服务器之间共享单个“上帝令牌”。
4. ** everywhere 强制执行 TLS。** 没有 HTTPS 的 Streamable HTTP 在生产环境中是绝对禁止的。
5. 验证和清理工具输出。 像对待用户输入一样对待工具返回的数据，不要盲目信任。
6. 限制工具调用速率。 失控的代理循环调用工具数千次可能会耗尽 API 配额或导致意外的副作用。
7. 审计并记录每个工具调用。 包括请求 ID、时间戳、调用模型和工具参数。你需要这些用于调试和安全事件响应。

调试 MCP：Inspector、日志记录和常见错误

你会遇到错误。每个开发者都会。以下是如何快速修复它们。

MCP Inspector 是官方调试工具，也是你的第一道防线。它连接到任何 MCP 服务器，发现其工具/资源/提示词，并允许你手动调用它们，同时显示原始 JSON-RPC 流量。

# Launch Inspector against your Python server
npx @modelcontextprotocol/inspector python weather_server.py

# Or against a TypeScript server
npx @modelcontextprotocol/inspector npx tsx weather-server.ts

Inspector 打开一个基于浏览器的 UI，包含工具、资源、提示词的选项卡以及通知窗格。你可以使用自定义参数调用任何工具，并准确查看线路上发送的 JSON。在连接到宿主应用程序之前使用它，独立调试服务器要容易得多。

常见错误和修复

• Claude Desktop 中“未找到服务器”，几乎总是 claude_desktop_config.json 中的路径问题。仔细检查 command 是否解析为真实的二进制文件，以及 cwd 是否指向正确的目录。在 macOS 上，使用绝对路径。
• 工具模式验证失败，如果模型发送的参数与工具的 inputSchema 不匹配，服务器将拒绝调用。检查你的模式类型是否与模型期望的一致。Zod（TypeScript）和类型提示（Python）会在定义时捕获大多数此类错误。
• 传输连接断开，对于 stdio，这通常意味着服务器进程崩溃。检查 stderr 输出。对于 Streamable HTTP，验证超时设置，长时间运行的工具可能会超过默认 HTTP 超时。
• “权限被拒绝”或 401 错误，OAuth 范围太窄。服务器拒绝令牌，因为它没有所需的权限。扩大范围，但仅限于工具实际需要的程度。

日志记录最佳实践

使用请求 ID 构建你的日志，以便你可以跨 MCP 客户端、服务器和任何下游 API 跟踪单个用户请求。记录每个 tools/call 调用，包括工具名称、参数、响应时间和结果状态。在生产环境中，将这些日志发送到可观测性平台，当凌晨 3 点出现问题时，你会庆幸自己这么做了。

Techsy 如何使用 MCP 构建

自 2025 年初以来，我们一直将 MCP 集成到客户项目中，我们最常看到的模式是：一个团队有一个 AI 功能，适用于一个模型和少数工具，但他们计划扩展——更多模型、更多数据源、更多代理能力。那是 MCP 开始产生回报的转折点。

我们的方法遵循三个步骤：

1. 评估适用性。 并非每个项目都需要 MCP。如果你从单个模型调用两个工具，函数调用更简单，我们会告诉你这一点。当你连接 3 个以上数据源、支持多个模型或构建需要可发现工具的代理工作流时，MCP 才有意义。
2. 独立构建和测试服务器。 我们为每个数据源开发自定义 MCP 服务器——内部数据库、SaaS API、专有服务——并在连接到任何 Host 之前使用 MCP Inspector 验证它们。
3. 使用 Streamable HTTP 和 OAuth 2.1 部署。 对于生产环境，我们将 MCP 服务器作为容器化服务运行在 TLS 后面，从第一天起就使用范围受限的 OAuth 令牌和结构化日志记录。没有静态秘密。

我们构建的最常见集成：将 AI 助手连接到内部 Postgres 数据库，为客户 SaaS 平台构建自定义 MCP 服务器，以及将团队从零散的函数调用设置迁移到标准化的 MCP 架构。

构建需要连接到你基础设施的 AI 驱动工具？我们帮助团队架构和实施 MCP 集成。获取免费咨询

关于 MCP 的常见问题

什么是模型上下文协议 (MCP)？

MCP 是一项开放标准，最初由 Anthropic 创建，现由 Linux Foundation 管理，定义了 AI 模型如何连接到外部工具、数据源和服务。它标准化了集成层，因此一个 MCP 服务器可以与任何兼容的模型一起工作，就像 AI 的通用插头。

MCP 如何工作？

MCP 使用三部分架构：Host 应用程序（如 Claude Desktop 或 Cursor）、Host 内部管理连接的 MCP Client，以及暴露工具和数据的 MCP Servers。所有通信都使用通过 stdio（本地）或 Streamable HTTP（远程）传输的 JSON-RPC 2.0 消息。

MCP 用于什么？

常见用例包括将 AI 助手连接到数据库（Postgres、MySQL）、与代码平台集成（GitHub、GitLab）、访问 SaaS 工具（Slack、Notion、Google Drive），以及构建需要与现实世界服务交互的自主 AI 代理。

MCP 与函数调用相同吗？

不。函数调用是特定于模型的（OpenAI 的格式与 Anthropic 的不同）且每次请求都要发送，你在每次 API 调用中发送工具模式。MCP 是一种跨模型工作的标准化协议，支持工具发现，并包括除了函数执行之外的资源和提示词。

什么是 MCP 服务器？

MCP 服务器是通过 MCP 协议向 AI 模型暴露工具、资源和提示词的程序。它们以标准化接口包装外部 API 和数据源。示例包括 GitHub MCP 服务器（用于 PR 和 Issue 管理）和 Postgres MCP 服务器（用于数据库查询）。

我如何构建 MCP 服务器？

使用 Python 和 FastMCP (pip install fastmcp) 或 TypeScript 和官方 SDK (npm install @modelcontextprotocol/sdk)。将你的工具定义为装饰函数（Python）或注册的处理程序（TypeScript），然后运行服务器。请参阅上面的教程部分以获取完整的可运行代码，或按照我们的从头构建 MCP 服务器的分步指南进行完整演练。

MCP 安全吗？

协议本身支持用于身份验证和范围权限的 OAuth 2.1。然而，Astrix Security 的研究发现，88% 的现有 MCP 服务器实现依赖于静态秘密而不是 OAuth。协议在设计上是安全的，但大多数现实世界的部署尚未跟上。

哪些 LLM 支持 MCP？

Claude 自 2024 年 11 月创建以来就具有原生 MCP 支持。ChatGPT 于 2025 年 3 月添加了支持，Gemini 于 2025 年 4 月跟进。开源模型可以通过 LangChain 和 LlamaIndex 中的适配器使用 MCP。

MCP 和 REST API 有什么区别？

REST API 专为通用服务间通信而设计。MCP 专为 AI 模型交互而设计，它包括 REST 所没有的工具发现、模式协商、资源访问和提示词模板。你不会用 MCP 替换你的 REST API；它们服务于不同的层。

现在谁维护 MCP？

Linux Foundation 的代理式 AI 基金会（AAIF）于 2025 年 12 月成立，负责管理 MCP。它由 Anthropic、Block 和 OpenAI 联合创立。这种供应商中立的治理是企业采用 MCP 的关键原因。

MCP 中的 Streamable HTTP 是什么？

Streamable HTTP 是 2025 年 MCP 规范更新中添加的生产传输机制。它用更清晰的设计取代了旧的 HTTP+SSE 传输：客户端发送 HTTP POST 请求，服务器可以同步响应或通过 SSE 流式传输。它在负载均衡器后面工作，并支持标准 HTTP 身份验证。

有多少个 MCP 服务器？

当 MCP 于 2025 年 12 月捐赠给 AAIF 时，Linux Foundation 引用了 10,000+ 活跃服务器和每月 9700 万次 SDK 下载。生态系统涵盖数据库、代码工具、SaaS 集成、搜索引擎和云基础设施提供商。

结论

MCP 已从 Anthropic 的开源实验转变为连接 AI 模型与工具的行业标准协议，仅用了一年多一点的时间。以下是重点：

• MCP 解决了 M x N 问题，一个服务器适用于每个兼容的模型，一个客户端适用于每个服务器
• 你可以用不到 50 行 Python (FastMCP) 或 TypeScript 代码构建一个工作型 MCP 服务器
• 开发使用 stdio，生产使用 Streamable HTTP，传输选择很简单
• 使用 OAuth 2.1 保护你的服务器——88% 的当前实现没有这样做，这是一个真正的风险
• 生态系统已具备生产就绪性——10,000+ 服务器，所有主要 LLM，Linux Foundation 下的供应商中立治理

展望未来，2026 路线图侧重于通过新的 Tasks 原语进行代理间通信、增强的企业安全性以及用于交互式服务器驱动 UI 的 MCP Apps。MCP 不再仅仅是工具访问的协议，它正在成为代理式 AI 的基础设施层。

从上面的教程代码开始，在 MCP Inspector 中测试它，并将其连接到 Claude Desktop。你将在不到一小时内拥有一个工作型的 MCP 集成。

来源

• MCP 规范 (2025-11-25)
• MCP 授权规范
• MCP 传输规范
• MCP Inspector 文档
• 介绍模型上下文协议，Anthropic
• 将 MCP 捐赠给 Linux Foundation，Anthropic
• Linux Foundation AAIF 公告
• Google Cloud MCP 支持
• FastMCP Python SDK
• MCP TypeScript SDK
• Astrix Security：2025 年 MCP 服务器安全状况
• MCP 2026 路线图