## 题目 1：MCP Server 一般怎么实现？

### 题目分类
- 方向：AI Agent 架构与设计模式

### 考察点
- 是否理解 MCP Server 在 Agent 系统里的职责边界，而不是把它简单等同于普通 HTTP API。
- 是否能说清楚 tools、resources、prompts、transport、schema、handler 的关系。
- 是否知道 MCP Server 的基本实现流程：能力建模、协议注册、参数校验、业务执行、结果返回、日志观测。
- 是否能意识到生产环境里的权限、幂等、超时、结果大小、工具误调用和多租户隔离问题。
- 是否能用代码说明一个最小 MCP Server 如何暴露工具，并解释模型、Host、Client、Server 各自负责什么。

### 知识讲解

#### 1. 核心概念
MCP Server 可以理解成 Agent 生态里的“能力适配层”。它不负责让模型变聪明，也不直接替模型做决策，而是把外部系统的数据和动作，用统一协议暴露给 MCP Client，让 Host 里的模型或应用可以发现、读取和调用。

在 MCP 里，Host 通常是 AI 应用，比如 IDE、聊天应用或 Agent 平台；Client 是 Host 里连接某个 MCP Server 的协议客户端；Server 是真正提供能力的一端。Server 暴露的能力主要有三类：tools 用来执行动作或查询外部系统，resources 用来提供上下文数据，prompts 用来提供可复用的提示模板或工作流。

一个好理解的类比是：普通后端 API 是给人写的应用调用的，MCP Server 是给 AI 应用接入外部能力用的协议适配器。它背后仍然可能调用数据库、RPC、SaaS API 或本地文件，但对外要按 MCP 的能力、消息和传输方式来描述自己。

图解 1：下面这张图展示 MCP Server 的实现分层，重点看清楚协议层、能力层和业务系统之间的边界。

![image.png](https://developer.qcloudimg.com/http-save/yehe-8338883/efe3c17dd9095a301a702ff0e81c81b8.png)

#### 2. 一般实现结构
实现 MCP Server 时，通常不是先写一堆业务函数，而是先回答三个问题：要暴露什么能力，谁可以调用，调用结果应该以什么形式返回给模型。

第一层是传输层。常见方式是 stdio 和 Streamable HTTP。stdio 适合本地工具或桌面应用集成，Client 启动 Server 子进程，通过标准输入输出交换 JSON-RPC 消息；Streamable HTTP 更适合远程服务、多客户端连接和 Web 服务化部署。

第二层是协议和能力注册。Server 要声明自己支持哪些 capability，比如 tools、resources、prompts，并为每个工具定义 name、description、input schema。这个 schema 很重要，它不是文档装饰，而是模型选择工具、Host 展示工具、Server 校验参数的共同契约。

第三层是 handler。handler 里做参数校验、权限检查、业务执行、错误映射和结果裁剪。比如查询订单工具，不能因为模型传了一个 orderId 就直接查库返回全部字段；Server 需要确认调用者是否有权限、字段是否允许返回、结果是否过大、下游超时怎么处理。

#### 3. 调用流程
一次典型工具调用不是“模型直接执行函数”。更准确的链路是：Host 连接 MCP Server，Client 先发现能力；模型在上下文里看到可用工具描述后，决定是否发起工具调用；Host/Client 把调用请求发给 MCP Server；Server 校验并执行 handler；结果再返回给 Host，由模型结合结果继续生成回答。

这条链路里，模型负责推理和选择意图，MCP Server 负责提供可执行能力和可信边界，Host 负责把模型、用户界面、工具调用、结果回填和安全确认串起来。面试里能把这个责任边界讲清楚，比单纯背 `registerTool` 更重要。

图解 2：下面这张图展示一次 tool 调用从发现到执行再到回填的链路，以及生产环境应该加在哪些控制点。
![image.png](https://developer.qcloudimg.com/http-save/yehe-8338883/b9f5e7fc299b385b931d777fb474fb2d.png)

#### 4. 关键工程边界
MCP Server 最容易被低估的是安全和可控性。工具描述越开放，模型越容易误选；参数 schema 越宽，handler 越容易收到脏参数；结果返回越大，越容易污染上下文并增加 token 成本；写操作没有幂等控制，重试时就可能重复下单、重复发邮件或重复改数据。

生产实现里，读操作和写操作最好有不同治理策略。读操作关注权限、字段脱敏、结果裁剪和缓存；写操作还要关注用户确认、幂等键、审计日志、回滚策略和人审门槛。远程 MCP Server 还需要认证授权、多租户隔离、限流、Host 头校验、请求大小限制和跨域边界。

还有一个常见问题是把 MCP Server 做成“万能工具箱”。工具越多、描述越模糊，模型选择工具越不稳定。更好的方式是按业务场景设计少量高质量工具，让工具名、描述、参数和返回结构都服务于模型决策，而不是把所有内部接口原样暴露出来。

#### 5. 常见误区
MCP Server 不是让模型绕过应用权限直接访问后端，也不是把企业系统裸露给大模型。它应该是一个受控适配层，所有危险动作都要经过 Server 侧校验和 Host 侧确认。

MCP Server 也不等同于 Function Calling。Function Calling 或 Tool Calling 更偏模型 API 里的工具调用机制，MCP 则是 AI 应用和外部能力之间的标准连接协议。两者可以配合使用：Host 可以把 MCP Server 暴露的工具转成模型可见的工具描述，模型选择工具后再由 Host 调用对应 MCP Server。

#### 6. 评估与调试
调试 MCP Server 不能只看工具是否能跑通，还要看工具是否容易被模型正确选择。至少要保留 tool list、tool call arguments、permission decision、handler latency、downstream error、result size、final answer quality 这些日志字段。

比较实用的测试集包括：参数缺失、参数类型错误、无权限访问、超时、下游异常、超大结果、重复请求、写操作重试、多租户越权、恶意输入混入工具参数、工具结果里包含提示注入文本。能把这些边界测出来，才算是可上线的 MCP Server。

### 代码示例

下面是一个简化的 TypeScript 示例，写法参考官方 TypeScript SDK 的 MCP Server 注册方式。不同 SDK 版本的 import 路径可能会调整，面试里重点看能力注册、schema 校验、handler 边界和 transport 连接。真实项目里还会补充认证、配置、日志中间件和部署脚本。

```ts
import { McpServer } from "@modelcontextprotocol/server";
import { StdioServerTransport } from "@modelcontextprotocol/server/stdio";
import * as z from "zod/v4";

type UserContext = {
  userId: string;
  roles: string[];
};

const server = new McpServer({
  name: "order-mcp-server",
  version: "1.0.0",
});

async function getUserContext(): Promise<UserContext> {
  // 真实项目里通常来自 Host 注入、token 解析或网关认证。
  return { userId: "u_123", roles: ["support"] };
}

async function queryOrder(orderId: string) {
  // 这里代表业务系统调用，可以是数据库、RPC 或第三方 API。
  return {
    orderId,
    status: "paid",
    amount: 199,
    internalRiskScore: 0.82,
  };
}

server.registerTool(
  "get_order_status",
  {
    description: "Query a user's order status by order id.",
    inputSchema: z.object({
      orderId: z.string().min(3).max(64),
    }),
  },
  async ({ orderId }) => {
    const user = await getUserContext();

    if (!user.roles.includes("support")) {
      throw new Error("permission_denied");
    }

    const order = await queryOrder(orderId);

    return {
      content: [
        {
          type: "text",
          text: JSON.stringify({
            orderId: order.orderId,
            status: order.status,
            amount: order.amount,
          }),
        },
      ],
    };
  },
);

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

### 代码讲解

这段代码的核心不是 `queryOrder`，而是 MCP Server 如何把一个业务能力包装成模型可发现、Host 可调用、Server 可校验的工具。`registerTool` 里的名称和描述会影响模型是否选中这个工具；`inputSchema` 既给模型提供参数结构，也给 Server 侧提供输入约束。

handler 执行时不能信任模型传来的参数。示例里先拿用户上下文，再做角色判断，然后调用业务系统，最后只返回允许进入模型上下文的字段。`internalRiskScore` 没有返回，就是为了强调 MCP Server 不应该把内部字段原样塞回模型。

stdio transport 表示这个 Server 可以被 Host 作为本地子进程启动，通过标准输入输出交换 MCP 消息。如果要做远程部署，可以换成 Streamable HTTP 相关 transport，但 handler、schema、权限和结果治理这些核心边界不会变。

### 工程优化与边界测试

延迟上，MCP Server 至少包含协议往返、handler 执行和下游系统调用。读工具可以做短缓存、结果裁剪和超时控制；写工具更应该关注幂等键、用户确认和审计，而不是盲目重试。返回给模型的结果要短而结构化，避免把一大段原始 JSON、HTML 或日志直接送进上下文。

测试时不要只测 happy path。需要覆盖参数错误、权限失败、下游超时、结果为空、结果过大、重复调用、取消请求、工具描述歧义、敏感字段泄露、多租户越权和工具结果里的 prompt injection。一个成熟的 MCP Server，应该能在这些边界上给出可预期的错误、日志和兜底行为。

### 面试回答

MCP Server 本质上是 Agent 系统里的能力适配层，它把外部系统的数据和动作包装成标准协议能力，让 AI 应用可以发现、读取和调用。实现它的关键不是“写一个函数给模型调”，而是把工具能力、上下文资源、协议传输、安全边界和可观测性一起设计好。

一个典型实现会先定义 Server 要暴露哪些能力。查询类、计算类、写操作更适合做成 tools；文档、文件、数据库 schema 这类上下文更适合做成 resources；可复用任务模板可以做成 prompts。然后为每个工具定义清晰的名称、描述和 input schema，让模型知道什么时候该用，也让 Server 能校验参数。

实现链路通常分成几步：选择 transport，本地集成常用 stdio，远程服务常用 Streamable HTTP；注册 Server capability；实现 tool/resource/prompt 的 handler；在 handler 里做参数校验、权限检查、业务调用、错误映射和结果裁剪；最后把日志、trace、超时、限流和审计补上。

这里最重要的责任边界是：模型只表达调用意图，不应该直接拥有后端权限；Host 负责连接模型、用户界面和 MCP Client；MCP Server 负责以受控方式执行外部能力。尤其是写操作，必须处理用户确认、幂等、重试和审计，否则 Agent 一旦误调用或重复调用，风险会比普通接口更高。

所以我判断一个 MCP Server 做得好不好，不只看它能不能被客户端连上，而是看工具描述是否稳定、参数 schema 是否收敛、权限是否可验证、结果是否适合进入上下文、错误是否可观测。MCP 的价值是把外部能力标准化接入 Agent 生态，但生产质量仍然取决于 Server 侧这些工程边界有没有兜住。

### 面试官追问
1. MCP Server 和普通 HTTP API 的区别是什么？为什么不直接让 Agent 调 HTTP 接口？
2. tools、resources、prompts 分别适合放什么？一个数据库查询应该设计成 tool 还是 resource？
3. stdio 和 Streamable HTTP 的适用场景有什么区别？
4. 如果模型频繁选错工具，你会从哪些层面优化？
5. MCP Server 里哪些操作需要 human-in-the-loop？
6. 写操作如何处理重试、幂等和审计？
7. 如何防止 MCP 工具返回内容里的 prompt injection 影响后续回答？
8. 如果一个 MCP Server 暴露了几十个工具，可能带来什么问题？

### 高分回答要点
- 能把 MCP Server 定位为 Agent 能力适配层，而不是普通函数集合。
- 能解释 Host、Client、Server、tools、resources、prompts、transport 的职责关系。
- 能说出实现步骤：能力建模、schema 定义、handler 实现、transport 接入、权限治理、日志观测。
- 能区分本地 stdio 和远程 Streamable HTTP 的场景。
- 能强调模型不直接执行后端业务，Server 必须负责校验、授权、错误处理和结果裁剪。
- 能提到写操作的幂等、用户确认、审计和回滚风险。
- 能提出调试指标：tool call 参数、命中工具、权限决策、handler 延迟、错误率、结果大小和最终回答质量。

### 常见扣分回答
- 只说 MCP Server 就是给大模型调用的 API，没有解释协议角色和能力类型。
- 把模型调用工具说成“模型直接执行函数”，忽略 Host 和 Server 的责任边界。
- 只会写最小 demo，不提权限、幂等、超时、日志、结果裁剪和多租户隔离。
- 把所有后端接口原样暴露成工具，忽略工具描述和 schema 对模型选择的影响。
- 不区分 tools 和 resources，把所有数据读取都设计成工具调用。
- 不知道 stdio 和 Streamable HTTP 的差异，也不知道本地集成和远程部署的取舍。

### 项目结合话术
我做 MCP Server 时会先从业务动作反推工具边界，而不是把内部接口一股脑暴露出去。读能力会重点控制权限、字段脱敏、结果大小和缓存；写能力会加用户确认、幂等键、审计日志和失败兜底。上线前会准备一组工具调用回放用例，覆盖正常调用、错参、越权、超时、重复调用和敏感字段泄露，并把 tool call、handler latency、error bucket、result size 和最终回答质量接到日志或 trace 里，这样模型选错工具或工具返回异常时能定位到具体层。

### 参考来源
- [Model Context Protocol Specification](https://modelcontextprotocol.io/specification/2025-06-18)
- [MCP Tools Specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)
- [MCP Resources Specification](https://modelcontextprotocol.io/specification/2025-06-18/server/resources)
- [MCP Transports Specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports)
- [Model Context Protocol TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk)

是否理解 MCP Server 在 Agent 系统里的职责边界，而不是把它简单等同于普通 HTTP API。

2026AI面试题-MCP Server 一般怎么实现？

人工智能

前端

MCPServer是Agent生态中的能力适配层，通过统一协议将外部系统数据与动作暴露给AI应用。实现核心在于能力建模、协议注册、参数校验、业务执行与结果裁剪，而非简单HTTP API。需明确tools、resources、prompts职责，处理权限、幂等、超时及多租户隔离，确保模型仅表达意图，Server执行受控操作。

代码解释

TypeScript 

中间件

数据库

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MCPServer是Agent生态中的能力适配层，通过统一协议将外部系统数据与动作暴露给AI应用。实现核心在于能力建模、协议注册、参数校验、业务执行与结果裁剪，而非简单HTTP API。需明确tools、resources、prompts职责，处理权限、幂等、超时及多租户隔离，确保模型仅表达意图，Server执行受控操...

2026AI面试题-MCP Server 一般怎么实现？-腾讯云开发者社区-腾讯云

2026AI面试题-MCP Server 一般怎么实现？

2026AI面试题-MCP Server 一般怎么实现？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐