什么是 MCP 服务器（MCP Server）？

工作原理

MCP Server 实现 Model Context Protocol 的能力提供方角色。它可以是封装文件或开发命令的本地子进程，也可以是适配数据库、SaaS API 和内部平台的远程服务。Host 负责模型编排、用户体验、同意与跨 Server 策略；MCP Client 向一个 Server 传递协议消息；Server 把已授权请求转换为边界明确的后端操作。它不是 LLM、Registry、Gateway、Authorization Server 或后端 Source of Truth，默认也只能看到 Request 显式携带的上下文，而不是完整对话。

协议版本是 Server 契约的一部分。在 MCP 2026-07-28 中，Core 是 Stateless：Server 必须依据每个 Request _meta 中的 Protocol Version 与相关 Client Capabilities 独立处理请求，必须实现 server/discover，并在不支持版本时通过 UnsupportedProtocolVersionError（-32022）返回可用版本。它不能从 Connection、Process 或 Response Stream 推断身份、能力、Task 或 Conversation。需要跨请求保存的业务状态必须由显式且受限的 Handle 标识，并在后续每个 Request 中传回。MCP 2025-11-25 及更早版本属于 Legacy，通过 initialize 与 notifications/initialized 建立协议状态；Dual-era Server 必须隔离 Modern 与 Legacy 语义，不能静默混用。

Server 只声明自己真正实现的 Primitive。Tool 是 Model-controlled Action，Resource 是以 URI 标识的 Application-controlled Context，Prompt 是交互约定下的 User-controlled Template；MCP 不强制某种 UI。Capability Discovery 不等于 Authorization。tools/list、resources/list 与 prompts/list 可以为空，也可根据当前 Request 携带的 Credential 裁剪，但不能仅因另一个 Request 复用了同一 Connection 就改变。列表顺序应稳定，并正确提供 Pagination Cursor、Cache Scope、TTL，以及只在已声明 Capability 支持时发送的 Change Notification。

Tool Contract 需要准确描述和有效 JSON Schema。未写 $schema 时默认使用 JSON Schema 2020-12；默认不得解析网络 $ref，Schema Composition 的深度与验证成本也应设限。执行前校验 Argument；声明 outputSchema 时，Server 必须确保 structuredContent 符合该 Schema。协议错误与领域失败应分开，输出 Byte 与媒体大小应受限，Description、Annotation、Resource Content、Prompt Content 和下游响应都必须按不可信数据处理。readOnlyHint 等 Annotation 只是元数据，不是操作无害或已获授权的证明。

当受支持的 tools/call、resources/read 或 prompts/get 操作需要 Elicitation、Sampling 或 Roots 时，Modern Server 通过 Multi Round-Trip Request 返回 resultType: "input_required"，而不是主动发起 JSON-RPC Request。经 Client 回传的 requestState 是攻击者可控输入；若它影响访问或行为，必须通过 HMAC 或 AEAD 保护完整性，并绑定已认证 Principal、短 TTL、Method 与关键参数摘要。若 Replay 可能重复副作用，还必须在服务端保证单次消费。Server 不能假设 Client 一定回答或重试。

当前标准 Transport 是 stdio 与 Streamable HTTP。stdio Server 从 stdin 读取逐行 JSON-RPC，只能向 stdout 写协议消息，日志写 stderr，并把 EOF 视为优雅退出信号。Modern HTTP Server 暴露单一 POST Endpoint，每次 Request 返回 JSON 或 Request-scoped SSE Stream；它应校验 Origin、Body/Header Protocol Version、Mcp-Method 和必要的 Mcp-Name；本地 Listener 应绑定 Loopback；响应流关闭表示取消时，应尽快停止对应工作。Protocol-level Session、独立 HTTP+SSE Transport、GET Stream 与 Stream Resume 属于 Legacy 或已移除能力，不是当前默认路径。

Authorization 在协议层可选，但受保护的 HTTP Server 是 OAuth Resource Server。它发布 Protected Resource Metadata，校验每个 Bearer Token 是否由可信 Issuer 签发给自己的 Audience，区分未认证 401 与 Scope 不足 403，并拒绝 Token Passthrough。Scope 只提供粗粒度权限边界；每个 Tool、Resource、Prompt、Tenant、Object、Purpose 与 Side Effect 仍需确定性的应用授权。stdio Server 从受限执行环境获取凭证，不套用 HTTP OAuth Profile，并应使用最小文件系统、进程与网络权限运行。

生产安全超出协议格式正确性。Server 需要清理 Resource URI 与 File Path、防止 Traversal 与无约束 Egress、隔离 Tenant 和下游 Credential、对高成本调用限流、传播 Timeout 与 Cancellation，并在可重试副作用前使用 Idempotency Key 或 Transaction Guard。Tool Output、Resource Text 或 Prompt Instruction 都不能覆盖 Host Policy。Trace 应绑定不可变 Server Build、Protocol Era/Revision、Transport、Principal/Tenant、Effective Policy、Method、Capability Revision、目标 Tool/Resource、Request ID、MRTR Step、Idempotency Decision、Latency、Error Class、Cancellation 与最终 Effect Status，但不得记录 Token、Secret 或无限制 Payload。

当多个兼容 Host 需要通过可发现、可版本化接口访问边界明确的能力域时，适合使用 MCP Server。现有 API 与数据库仍应作为权威后端；只有在需要 Fleet-level Routing、Inventory 或 Policy 时才增加 Gateway 或 Registry。符合 MCP 只能标准化发现与交换，不能自动证明集成可移植、可信、授权正确、幂等或具备生产可用性。

主要特点

• 明确角色边界：暴露协议能力，模型编排、同意和跨 Server 策略仍由 Host 管理
• 现代无状态契约：校验逐请求版本与能力，实现 server/discover，并用显式 Handle 保存持久状态
• 区分三类原语：Tool、Resource 与 Prompt 使用各自的发现、控制、Schema、缓存和错误语义
• 感知 Transport：正确实现 stdio Framing 或 Streamable HTTP Header、Origin、请求流、取消与退出
• Resource Server 安全：校验 Audience、Scope、Tenant、Object、Operation 与 Purpose，不接受 Token Passthrough 或盲信元数据
• 副作用可治理：限制输入输出、校验结果、保证重试幂等、隔离依赖并生成脱敏审计证据

常见用途

1. 通过 stdio 向本地编程 Host 暴露边界明确的只读代码仓库或文档能力
2. 把远程 SaaS 或内部 API 适配为具有 OAuth、对象级授权、限流和审计的 Tool
3. 发布按 Tenant 过滤的 Resource 与 URI Template，而不让模型直接访问底层数据库或文件系统
4. 提供用户选择的领域 Prompt，同时让其内容服从 Host Policy 与输入校验
5. 使用显式状态 Handle、有限重试和幂等副作用部署可水平扩展的 Streamable HTTP 实例

常见问题

相关工具

相关术语

相关文章