跳到主要内容

MCP 协议工程实战

5-7 讲了 MCP 的基础三原语和 Server 开发，02 Skills 讲了 Skills 与 MCP 的边界。本篇聚焦 2025-2026 年的新进展：远程 Server 标准化、OAuth、Sampling、多 Server 编排、Marketplace 治理。

学前说明​

MCP 在 2025 年经历了从"协议规范"到"生态成熟"的关键一年：

  • 2024-11：Anthropic 发布 MCP 0.1，stdio + 简单 SSE
  • 2025-03：Streamable HTTP 标准化，OAuth 2.1 集成
  • 2025-06：MCP Spec 2025-06-18，引入 Sampling、Elicitation
  • 2025-11：MCP Spec 2025-11-25（当前），Resources 大升级
  • 2026-Q1：主流厂商（OpenAI、Google、Microsoft）全面支持
  • 2026-Q2：MCP Marketplace 出现（类似 npm 之于 JavaScript）

如果你只熟悉 stdio + 本地 Server（5-7 讲的内容），你已经落后了一个时代。远程 Server 才是企业级 MCP 的主战场。

学习目标​

  • 区分本地 Server（stdio）和远程 Server（Streamable HTTP）的工程边界
  • 实现 OAuth 2.1 认证的 MCP Server（企业必须）
  • 用 Sampling 让 Server 反向调用 Client 的 LLM
  • 设计高阶 Resources（动态、订阅、模板化）
  • 编排多 MCP Server 与冲突解决
  • 评估和参与 MCP Marketplace 生态
  • 处理 2025-2026 暴露的安全问题（接 04 Lethal Trifecta）

与现有知识的衔接​

  • 5-7 MCP 与 Function-Calling 工程实践：基础协议（前置）
  • 02 Skills 体系与 Plugin 架构：Skills 与 MCP 边界
  • 04 Lethal Trifecta：MCP 安全的核心威胁

第一章：MCP 的真实定位​

1.1 一年后看 MCP​

5-7 写于 2025-05，那时 MCP 还在快速演进。一年后定位更清晰了：

MCP 是 AI 工具的"npm + HTTP API"：

  • 像 npm：标准化"工具包"，可以装、版本化、发布、共享
  • 像 HTTP API：标准化"远程能力调用"，跨语言、跨厂商

MCP 不是：

  • 不是 AI 框架（不替代 LangChain）
  • 不是模型（不替代 LLM）
  • 不是 RAG 系统（虽然能集成）

理解这个定位，决定你 MCP 工程怎么做。

1.2 三种典型部署形态​

经过 2025 一年沉淀，三种形态各有适用：

形态部署认证适合
本地 stdio子进程无个人工具、开发调试
远程 Streamable HTTPHTTP 服务OAuth 2.1企业服务、SaaS 集成
嵌入式（同进程）库导入无框架内部、SDK 集成

关键认知：早期 MCP 几乎都是本地 stdio。但生产 MCP 的未来是远程 HTTP——理由：

  • 工具更新不需要每个用户更新本地 Server
  • 凭证集中管理（不是每个用户配 token）
  • 可以统一审计、限流、监控
  • 跨平台、跨设备访问同一组工具

第二章：Streamable HTTP 标准化​

2.1 从 SSE 到 Streamable HTTP​

早期远程 MCP 用 SSE（Server-Sent Events）。2025 年 MCP 引入 Streamable HTTP——基于 HTTP 但支持双向流。

为什么换：

  • SSE 单向（Server → Client），双向通信复杂
  • Streamable HTTP 用 chunked transfer encoding 实现双向
  • 更好的代理/负载均衡兼容（标准 HTTP）
  • 支持 stateless 和 stateful 两种模式

2.2 Streamable HTTP 协议简述​

请求：

POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Session-Id: abc123  // 可选，stateful 时

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {...}
}

响应（流式）：

HTTP/1.1 200 OK
Content-Type: application/json+ndjson  // 或 text/event-stream
Transfer-Encoding: chunked

{"jsonrpc":"2.0","id":1,"result":{...}}\n

或 server push：

HTTP/1.1 200 OK
Content-Type: text/event-stream

data: {"jsonrpc":"2.0","method":"notifications/progress",...}\n\n
data: {"jsonrpc":"2.0","id":1,"result":{...}}\n\n

2.3 用 TypeScript SDK 搭远程 Server​

import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';
import express from 'express';

const app = express();
app.use(express.json());

// 每个 session 一个 Server 实例
const sessions = new Map<string, Server>();

app.post('/mcp', async (req, res) => {
  const sessionId = req.headers['mcp-session-id'] as string ?? crypto.randomUUID();
  
  let server = sessions.get(sessionId);
  if (!server) {
    server = createServerForUser(/* user info from auth */);
    const transport = new StreamableHTTPServerTransport({
      sessionIdGenerator: () => sessionId,
    });
    await server.connect(transport);
    sessions.set(sessionId, server);
  }
  
  await server.handleRequest(req, res);
});

app.listen(3000);

2.4 Stateful vs Stateless​

Stateful（有状态）：

  • Session 跨请求保持
  • 适合：长对话、订阅、连续操作
  • 用 Mcp-Session-Id header 识别

Stateless（无状态）：

  • 每个请求独立
  • 适合：单次工具调用、负载均衡友好
  • 不需要 session

工程建议：起步 stateless，遇到具体需求再升 stateful。Stateful 的 sticky session、负载均衡、故障转移都是工程负担。

第三章：OAuth 2.1 认证​

3.1 为什么必须 OAuth​

5-7 第 4.4 节用 Bearer Token 做认证。但生产场景下问题多：

  • Token 泄露后无法吊销（需要重启 Server）
  • 用户管理麻烦（哪个 token 是谁的？）
  • 权限粒度粗（一个 token 全部权限）
  • 不符合企业 IT 规范（SSO、SAML 集成）

MCP Spec 2025 强制要求远程 Server 支持 OAuth 2.1。

3.2 OAuth 2.1 in MCP​

MCP 用 OAuth 2.1 + PKCE：

3.3 实战：OAuth Server 部分​

import { OAuth2Server } from 'oauth2-server';
import { McpAuthMetadata } from '@modelcontextprotocol/sdk/server/auth.js';

// 1. 暴露 metadata（让 client 发现 OAuth endpoint）
app.get('/.well-known/oauth-authorization-server', (req, res) => {
  res.json({
    issuer: 'https://my-mcp.example.com',
    authorization_endpoint: 'https://my-mcp.example.com/oauth/authorize',
    token_endpoint: 'https://my-mcp.example.com/oauth/token',
    scopes_supported: ['mcp:read', 'mcp:write'],
    response_types_supported: ['code'],
    code_challenge_methods_supported: ['S256'],  // PKCE
  });
});

// 2. Authorization endpoint
app.get('/oauth/authorize', async (req, res) => {
  // 验证 client_id、PKCE challenge
  // 引导用户登录 + 授权
  // 返回 auth code
});

// 3. Token endpoint
app.post('/oauth/token', async (req, res) => {
  // 验证 auth code + PKCE verifier
  // 颁发 access_token + refresh_token
  res.json({
    access_token: '...',
    token_type: 'Bearer',
    expires_in: 3600,
    refresh_token: '...',
    scope: 'mcp:read mcp:write'
  });
});

// 4. MCP endpoint 验证 token
app.post('/mcp', async (req, res) => {
  const token = req.headers.authorization?.replace('Bearer ', '');
  const session = await validateToken(token);
  if (!session) {
    res.set('WWW-Authenticate', `Bearer realm="mcp", authorization_uri="https://my-mcp.example.com/.well-known/oauth-authorization-server"`);
    return res.status(401).send();
  }
  
  // session 包含 user_id、scopes、tenant_id
  // ... 处理 MCP 请求
});

3.4 Scope 设计​

OAuth scope 让权限可细分：

const scopes = {
  'mcp:read': 'Read-only access (list/call read tools)',
  'mcp:write': 'Read + write access',
  'mcp:admin': 'Admin operations',
  
  // 工具级
  'tool:get_user_info': 'Specific tool',
  
  // 数据范围
  'data:own': 'Only own data',
  'data:team': 'Team data',
};

3.5 Client 侧​

主流 MCP Client（Claude Desktop、Cursor）已经支持 OAuth：

{
  "mcpServers": {
    "company-crm": {
      "url": "https://crm.company.com/mcp",
      "auth": {
        "type": "oauth2"
        // Client 自动处理 OAuth flow
      }
    }
  }
}

用户首次连接时会弹浏览器走 OAuth 授权。Token 由 Client 安全存储。

第四章：Sampling — Server 反向调用 LLM​

4.1 Sampling 是什么​

MCP Spec 2025-06 引入的强大特性：Server 可以请求 Client 帮它调用 LLM。

为什么需要：

  • Server 不需要自己集成各家 LLM API
  • Server 不需要付 LLM 的钱（用 Client 的）
  • Server 自动适配 Client 用的模型
  • 用户的 LLM 凭证不外泄给 Server

4.2 工作流程​

关键点：Server 不直接调 LLM。所有 LLM 调用通过 Client 中转。

4.3 Server 端实现​

import { Server } from '@modelcontextprotocol/sdk/server/index.js';

const server = new Server(/* ... */, {
  capabilities: {
    tools: {},
    sampling: {},  // 声明需要 sampling
  }
});

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === 'summarize_document') {
    const docContent = await fetchDoc(request.params.arguments.docId);
    
    // 让 Client 帮我调 LLM 总结
    const result = await server.createMessage({
      messages: [
        {
          role: 'user',
          content: { type: 'text', text: `Summarize:\n\n${docContent}` }
        }
      ],
      maxTokens: 500,
      modelPreferences: {
        hints: [{ name: 'claude-sonnet' }],  // 偏好（Client 可能不遵守）
      }
    });
    
    return {
      content: [{ type: 'text', text: result.content.text }]
    };
  }
});

4.4 Client 端处理​

Client 收到 sampling 请求要决定：

  • 是否同意（用户可能要确认）
  • 用哪个 LLM
  • 是否限制（防止 Server 滥用）
// Client 处理 sampling
client.setRequestHandler(CreateMessageRequestSchema, async (request) => {
  // 1. 用户确认（高敏感场景）
  const userApproved = await promptUser({
    server: serverName,
    purpose: 'Server wants to use your LLM',
    messages: request.params.messages,
  });
  
  if (!userApproved) {
    throw new Error('User declined sampling');
  }
  
  // 2. 调 LLM
  const llmResponse = await llm.complete(request.params);
  
  // 3. 限流（防止 Server 滥用）
  await rateLimiter.check(serverName);
  
  return llmResponse;
});

4.5 适用场景​

Sampling 不是所有 MCP Server 都需要。适合：

  • 文档摘要 Server：不想集成多家 LLM
  • 代码分析 Server：用户已经有 LLM 凭证
  • 企业内部 Server：不想付 LLM 调用费
  • 多模型路由：让用户决定用什么模型

不适合：

  • 简单工具调用（不需要 LLM）
  • 延迟敏感场景（多了一跳）
  • Server 有自己的特殊模型（不想用通用 LLM）

第五章：Resources 高阶用法​

5.1 Resources vs Tools 再讨论​

5-7 提到 Resources 和 Tools 的区别：

  • Tools：AI 决定调用，有副作用
  • Resources：用户/Host 选择，只读数据

但 2025-2026 年 Resources 演进出更多用法。

5.2 动态 Resources​

Resource URI 可以是模板：

server.setRequestHandler(ListResourceTemplatesRequestSchema, async () => ({
  resourceTemplates: [
    {
      uriTemplate: 'github://issues/{owner}/{repo}/{number}',
      name: 'GitHub Issue',
      description: 'View a specific GitHub issue',
      mimeType: 'application/json'
    },
    {
      uriTemplate: 'db://customers/{customer_id}',
      name: 'Customer Record',
      description: 'View customer details',
    }
  ]
}));

// AI 可以动态请求：
// resource://github/issues/openai/codex/1234
// resource://db/customers/cus_abc

让 AI 能精确指定要看什么数据。

5.3 订阅 Resources​

Resources 可以"订阅"，发生变化时 Server 主动通知 Client：

server.setRequestHandler(SubscribeRequestSchema, async (req) => {
  const { uri } = req.params;
  
  // 注册订阅
  watchResource(uri, (newContent) => {
    // 推送变化
    server.notification({
      method: 'notifications/resources/updated',
      params: { uri }
    });
  });
  
  return {};
});

适合：

  • 监控某个文件
  • 监控数据库表变化
  • 实时数据流

5.4 大型 Resources 分页​

资源大时不能一次性返回：

server.setRequestHandler(ReadResourceRequestSchema, async (req) => {
  const { uri } = req.params;
  
  // 解析 URI 中的分页参数
  // db://logs?page=1&size=100
  const url = new URL(uri);
  const page = parseInt(url.searchParams.get('page') ?? '1');
  
  const data = await db.queryLogs({ page, size: 100 });
  
  return {
    contents: [{
      uri,
      mimeType: 'application/json',
      text: JSON.stringify(data),
      // 提示下一页
      _meta: { nextPage: data.hasMore ? page + 1 : null }
    }]
  };
});

5.5 二进制 Resources​

不只是文本：

server.setRequestHandler(ReadResourceRequestSchema, async (req) => {
  if (req.params.uri.startsWith('image://')) {
    const imageData = await fetchImage(...);
    return {
      contents: [{
        uri: req.params.uri,
        mimeType: 'image/png',
        blob: imageData.toString('base64')
      }]
    };
  }
});

支持图片、PDF、音频等。Client 决定怎么呈现给 LLM（视觉模型可以直接看）。

第六章：多 MCP Server 编排​

6.1 现实：用户装一堆 Server​

典型用户配置：

{
  "mcpServers": {
    "filesystem": {...},
    "github": {...},
    "slack": {...},
    "linear": {...},
    "postgres": {...},
    "browser": {...}
  }
}

每个 Server 几个工具，加起来 50-100 个工具。问题：

  1. AI 选错工具（参考 5-7 第 6.3 节）
  2. 工具名冲突（get_user 在多个 Server 都有）
  3. 凭证管理混乱
  4. 加载时间长（每次启动都要 init 所有 Server）

6.2 Tool Namespacing​

MCP Spec 2025-11 推荐工具名加前缀：

github_get_issue  ← Server 自己加前缀
slack_get_channel

或者 Client 自动加：

mcp.github.get_issue  ← Client 加 namespace
mcp.slack.get_channel

6.3 工具选择 Router​

工具数量大时，引入 Router 模式：

// 第一层：Router LLM 决定用哪个 Server
async function route(userMessage: string) {
  const decision = await haiku.classify({
    message: userMessage,
    options: [
      { id: 'github', description: '代码、PR、issue' },
      { id: 'slack', description: '消息、频道' },
      { id: 'postgres', description: '数据库查询' },
    ]
  });
  
  // 第二层：只暴露选中的 Server 的工具
  return loadOnly(decision.id);
}

每次只让 LLM 看到 5-10 个相关工具，准确率显著提升。

6.4 工具冲突解决​

两个 Server 都提供 search：

// Client 智能去歧义
const tools = mergeTools(githubTools, slackTools);

// 自动重命名
// search → github_search, slack_search

// 或者根据上下文选择
function disambiguate(userMessage: string) {
  if (userMessage.includes('代码') || userMessage.includes('PR')) {
    return 'github_search';
  }
  if (userMessage.includes('消息')) {
    return 'slack_search';
  }
  // 默认两个都暴露给 LLM
}

6.5 Server 编排模式​

模式 A：扁平（默认）

所有 Server 平级，Client 把所有工具喂给 LLM。

适合：< 30 个工具。

模式 B：分组（Grouped）

按业务分组，用户/AI 选组：

代码组：github + filesystem + git
通讯组：slack + email + linear
数据组：postgres + analytics

模式 C：Meta-Server

一个 MCP Server 内部代理多个：

// 自建 meta-server
class MetaServer {
  private servers: Map<string, MCPClient>;
  
  async listTools() {
    // 聚合所有子 server 的工具
  }
  
  async callTool(name: string, args: any) {
    // 路由到对应子 server
    const [serverName, toolName] = name.split('.');
    return this.servers.get(serverName)!.callTool(toolName, args);
  }
}

适合：企业内部，统一治理。

第七章：MCP Marketplace 与生态​

7.1 Marketplace 现状（2026）​

  • Anthropic 官方仓库：modelcontextprotocol/servers
  • npm：搜索 @modelcontextprotocol/ 前缀
  • Smithery、Pulse MCP 等第三方目录
  • Claude Desktop / Cursor 内置 marketplace

7.2 评估第三方 Server​

装 MCP Server 等于装 npm 包——有供应链风险。评估清单：

维度检查
来源官方 / 知名公司 / 个人开发者
Star、download 量> 1k 比较安全
更新频率半年内有更新
维护者是否有商业实体或活跃个人
源代码是否开源、能 review
权限范围这个 Server 真的需要这些权限吗
声誉社区 issue 反馈

警告信号：

  • 名字像知名 Server 但作者是无名小号（typosquatting）
  • 最近一次更新很久前
  • 闭源但要求高敏感权限
  • 评论里提到安全问题

7.3 自建团队 Marketplace​

企业内部 MCP Server 集合：

team-mcp-registry/
├── servers/
│   ├── crm/
│   │   ├── package.json
│   │   ├── src/
│   │   └── README.md
│   ├── jira-internal/
│   └── deploy-tool/
├── docs/
│   └── installation.md
└── CHANGELOG.md

通过私有 npm registry / GitHub package 分发：

// 工程师本地配置
{
  "mcpServers": {
    "crm": {
      "command": "npx",
      "args": ["-y", "@my-company/mcp-crm"],
      "env": {
        "AUTH_TOKEN": "${TEAM_TOKEN}"
      }
    }
  }
}

7.4 治理流程​

每个团队级 MCP Server 需要：

  • PR review：不只代码，还有"这个工具该不该存在"
  • 安全审查：参考第八章
  • 版本管理：semver，breaking change 提前通知
  • 使用追踪：哪些团队/用户在用
  • 审计日志：所有调用记录

第八章：MCP 安全升级（2025-2026）​

8.1 已暴露的真实漏洞​

2025 年公开的 MCP 安全事件：

  • 2025-04：MCP Prompt Injection 论文（Simon Willison 报道）
  • 2025-05：GitHub MCP Exploit（参考 04 Lethal Trifecta）
  • 2025-06：CaMeL 论文提出防御
  • 2025-08："Summer of Johann"（一系列 prompt injection 利用）
  • 2025-11：Agents Rule of Two（Meta 论文）

每次都揭示 MCP 的同样问题：工具被滥用 + 不可信内容注入。

8.2 协议级安全升级​

MCP Spec 2025-11 引入：

1. Server 元数据声明

{
  capabilities: {
    tools: {
      listChanged: true,
    }
  },
  metadata: {
    securityLevel: 'high',
    handlesUntrustedContent: true,  // ⚠️ 警告标志
    requiresExplicitApproval: ['delete_*', 'send_*'],
  }
}

Client 看到 handlesUntrustedContent: true 时，应该限制此 Server 的能力组合（Lethal Trifecta 防御）。

2. Tool 风险标签

{
  name: 'delete_user',
  description: '...',
  inputSchema: {...},
  metadata: {
    riskLevel: 'critical',
    idempotent: false,
    requiresApproval: true,
  }
}

Client UI 给 critical 工具加红色警告 + 强制人工确认。

3. Audit Trail 标准化

所有工具调用必须有 audit log，Spec 定义统一格式：

{
  "timestamp": "2026-06-12T...",
  "session_id": "...",
  "tool_call": {
    "server": "github",
    "name": "create_pr",
    "args_hash": "sha256:..."  // 不存原文
  },
  "user_consent": "explicit_approval",
  "approver_id": "..."
}

8.3 Client 侧防御实现​

class SafeMCPClient {
  async callTool(server: string, name: string, args: any) {
    // 1. 检查 Server 风险等级
    const serverMeta = this.getServerMeta(server);
    
    // 2. 检查 Tool 风险等级
    const toolMeta = this.getToolMeta(server, name);
    
    // 3. Lethal Trifecta 检查
    if (this.detectsTrifecta(server, name)) {
      throw new Error('Lethal Trifecta detected, refusing');
    }
    
    // 4. 高风险工具人工确认
    if (toolMeta.riskLevel === 'critical' || toolMeta.requiresApproval) {
      const approved = await this.askUser({
        server, name, args,
        risk: toolMeta.riskLevel,
      });
      if (!approved) throw new Error('User declined');
    }
    
    // 5. 限流
    await this.rateLimit.check(server, name);
    
    // 6. 调用
    const result = await this.client.callTool({ name, arguments: args });
    
    // 7. 审计
    await this.audit.log({...});
    
    return result;
  }
  
  detectsTrifecta(server: string, tool: string): boolean {
    // 检查当前 session 已加载的工具
    const loadedTools = this.getLoadedTools();
    
    const hasPrivateData = loadedTools.some(t => 
      this.getToolMeta(...).accessesPrivateData
    );
    const hasUntrustedInput = loadedTools.some(t => 
      this.getToolMeta(...).readsUntrustedContent
    );
    const hasExternalComm = loadedTools.some(t => 
      this.getToolMeta(...).externallyCommunicates
    );
    
    return hasPrivateData && hasUntrustedInput && hasExternalComm;
  }
}

8.4 用户教育​

最重要：告诉用户"装 MCP Server 像装 Chrome 扩展，要谨慎"。

应用层 UI 应该：

  • 第一次装某个 Server 显著提示
  • 配置页清楚展示每个 Server 的工具列表 + 权限
  • 提供"一键禁用所有 MCP Server"开关

第九章：生产级 MCP Server 架构​

9.1 完整架构图​

9.2 关键组件​

1. API Gateway

  • TLS 终结
  • OAuth token 验证
  • 限流（per user / per tenant）
  • CORS（如果浏览器 Client）
  • 日志、metrics

2. MCP Server

  • 协议处理
  • Session 管理
  • Capability 协商

3. Tool Gateway

  • 权限决策（用 OAuth scope）
  • 工具调用记录
  • 风险评估

4. 工具实现

  • 业务逻辑
  • 调用后端

9.3 多租户隔离​

// 关键：tenant 信息从 OAuth token 提取，而不是参数
async function getCustomerInfo(args: { customerId: string }, ctx: ToolContext) {
  // ctx.tenantId 来自 token
  const customer = await db.query(
    'SELECT * FROM customers WHERE id = $1 AND tenant_id = $2',
    [args.customerId, ctx.tenantId]  // 强制租户过滤
  );
  
  if (!customer) {
    throw new Error('not_found_or_no_permission');
  }
  
  return customer;
}

9.4 性能优化​

1. Tool listing 缓存

// 工具列表很少变，缓存
let cachedTools: Tool[] | null = null;

server.setRequestHandler(ListToolsRequestSchema, async () => {
  if (!cachedTools) {
    cachedTools = await loadTools();
  }
  return { tools: cachedTools };
});

// 工具变化时 invalidate
function onToolsChanged() {
  cachedTools = null;
  server.notification({ method: 'notifications/tools/list_changed' });
}

2. 后端调用并行

async function listResources() {
  // ❌ 串行
  const a = await fetchA();
  const b = await fetchB();
  
  // ✅ 并行
  const [a, b] = await Promise.all([fetchA(), fetchB()]);
}

3. 流式响应

大数据用 streaming，不要一次返回 50MB JSON。

9.5 监控指标​

指标健康范围
请求 P95 延迟< 500ms
Tool 调用错误率< 1%
OAuth 失败率< 0.5%
Trifecta 触发警告次数接近 0
高风险 Tool 人工拒绝率关注异常
Active sessions容量规划

第十章：踩坑总结​

10.1 协议层​

坑表现修正
用 SSE 不用 Streamable HTTP跟不上 spec升级 SDK
Stateful 但无 sticky session多实例时 session 不一致用 Redis 共享或上 sticky
无 OAuth 用静态 token凭证泄露不能吊销上 OAuth 2.1

10.2 工程层​

坑表现修正
工具数量 > 30AI 选错率高Router 模式
工具描述不清误用详细 description + 反例
无 audit出事不可追强制日志
用第三方 Server 不审计供应链攻击评估 + 锁版本

10.3 安全层​

坑表现修正
凑齐 Lethal Trifecta数据泄露风险Rule of Two
高风险工具无确认误操作强制 approval
跨租户数据泄露tenant_id 没强制在 query 层强制
Sampling 滥用Server 滥用用户 LLMRate limit + 用户确认

第十一章：未来方向​

11.1 MCP 标准化深化​

预期 2026 年：

  • ISO/W3C 标准化讨论
  • 跨厂商互操作性测试
  • 安全标准（类似 OWASP for MCP）

11.2 MCP + WebRTC​

直接浏览器对浏览器（P2P）的 MCP？讨论中：

  • 不依赖中心 Server
  • 适合协作 AI

11.3 MCP Federation​

多个 MCP Server 联邦——一个 Server 可以"代理"其他 Server 的工具，自动路由：

Client → meta-server → [github / slack / linear / ...]

类似 ActivityPub 之于社交，让 MCP 生态网状化。

11.4 局部计算 MCP​

Tool 不只在 Server 端跑，可以在 Client 端跑（保护数据）：

  • Server 提供"工具定义"
  • Client 本地执行
  • 结果不出本地

适合极敏感数据。

权威资料​

核对日期：2026-06-12