11 MCP面试题

1、什么是MCP？

MCP 是 Model Context Protocol 的缩写，中文可以理解为“模型上下文协议”。

它是 Anthropic 提出的一个开放协议，主要用来连接大模型应用和外部系统，比如文件系统、数据库、搜索服务、业务 API、代码仓库、内部工具等。

简单说，MCP 想解决的是：让 AI 应用用统一的方式接入外部能力，而不是每接一个工具都重新写一套适配逻辑。

可以把 MCP 理解成 AI 应用里的“标准接口层”。

以前一个 Agent 要接数据库、GitHub、Slack、文件系统，可能要分别写不同的集成代码：

text

Agent -> 数据库 SDK
Agent -> GitHub API
Agent -> Slack API
Agent -> 本地文件 API

有了 MCP 后，可以变成：

text

Agent / MCP Client -> MCP Server -> 外部系统

MCP Server 负责把外部系统包装成标准能力，MCP Client 负责发现和调用这些能力。这样模型应用不用关心每个系统的底层细节，只需要按 MCP 协议交互。

2、MCP解决了什么问题？

MCP 主要解决的是大模型应用接入外部工具和上下文时缺少统一标准的问题。

在没有 MCP 之前，每个 AI 应用都要自己定义工具格式、调用方式、权限处理和上下文传递方式。这样会带来几个问题。

第一，重复开发。

同一个数据库查询能力，可能要给 Claude Desktop 写一套，给内部 Agent 平台写一套，给 IDE 插件再写一套。

第二，工具难复用。

工具和某个应用强绑定，换一个宿主环境就要重新适配。

第三，接入方式不统一。

有的工具用 HTTP，有的用 SDK，有的用命令行，有的需要本地权限，Agent 层会变得很乱。

第四，安全边界不好管理。

工具散落在各处时，权限、审计、确认机制也容易分散。

MCP 的作用就是定义一套标准，让工具、资源、提示词等能力可以被统一暴露和调用。

它解决的不是“模型会不会调用工具”的问题，而是“工具如何以标准方式提供给模型应用”的问题。

3、MCP和Function Calling有什么区别？

MCP 和 Function Calling 都和工具调用有关，但它们不是一回事。

Function Calling 是模型能力层面的概念。它解决的是：模型如何根据用户意图，生成结构化的函数名和参数。

比如模型输出：

json

{
  "name": "get_weather",
  "arguments": {
    "city": "北京"
  }
}

MCP 是工具接入协议。它解决的是：这些工具从哪里来、如何被发现、如何描述、如何调用、如何返回结果。

可以这样理解：

text

Function Calling：模型决定调用哪个函数、传什么参数
MCP：应用通过标准协议发现和执行外部工具

两者可以配合使用。

例如：

text

用户提问
  ↓
模型通过 Function Calling 决定调用 search_docs
  ↓
MCP Client 按 MCP 协议调用 MCP Server 上的 search_docs
  ↓
MCP Server 执行真实搜索并返回结果
  ↓
模型基于结果生成回答

所以 Function Calling 更偏模型和工具调用格式，MCP 更偏工具生态和运行协议。

4、MCP协议核心组成有哪些？

MCP 的核心组成可以分成几类。

第一，Host。

Host 是用户直接使用的 AI 应用，比如 Claude Desktop、IDE 插件、Agent 平台等。它负责承载整个交互体验。

第二，MCP Client。

Client 通常运行在 Host 内部，负责和 MCP Server 建立连接、发现能力、发送请求、接收结果。

第三，MCP Server。

Server 负责把外部系统包装成 MCP 能力，比如文件系统 Server、数据库 Server、Git Server、企业内部系统 Server。

第四，Tools。

Tools 是可执行的动作，比如查询数据库、搜索文档、读取文件、创建工单。它们通常会有名称、描述和输入参数 schema。

第五，Resources。

Resources 是可读取的上下文资源，比如文件内容、数据库记录、文档页面等。它更偏“提供信息”，不一定是执行动作。

第六，Prompts。

Prompts 是 MCP Server 暴露出来的提示词模板，方便 Host 或模型复用某些标准任务模板。

第七，Transport。

Transport 是通信方式。MCP 可以通过 stdio、HTTP/SSE 等方式通信。stdio 常见于本地工具，HTTP 更适合远程服务。

整体关系可以这样看：

text

Host
  ↓
MCP Client
  ↓
MCP Server
  ├── Tools
  ├── Resources
  └── Prompts

5、MCP Client和MCP Server是什么？

MCP Client 是调用方，MCP Server 是能力提供方。

MCP Client 通常嵌在 AI 应用里，负责连接一个或多个 MCP Server。它会向 Server 查询有哪些工具、资源和提示词，也会把工具调用请求发送给 Server。

MCP Server 则负责把某个外部系统包装成标准接口。

比如一个文件系统 MCP Server，可以提供：

text

read_file
write_file
list_directory

一个数据库 MCP Server，可以提供：

text

list_tables
query_database
get_schema

一个 GitHub MCP Server，可以提供：

text

list_issues
create_issue
get_pull_request

Client 不需要知道这些能力底层是怎么实现的，只需要按 MCP 协议调用。

两者的关系类似：

text

MCP Client：我需要调用 search_docs，参数是 query=报销规则
MCP Server：我来执行真实搜索，然后把结果返回给你

实际系统中，一个 Host 可以连接多个 MCP Server。比如一个代码助手同时连接文件系统 Server、Git Server、数据库 Server 和内部文档 Server。

6、MCP如何发现工具？

MCP 的工具发现是通过协议完成的，不需要在 Agent 代码里手写所有工具列表。

当 MCP Client 连接到 MCP Server 后，会向 Server 请求当前可用的工具列表。Server 返回每个工具的名称、描述和输入参数 schema。

工具信息一般包括：

json

{
  "name": "search_docs",
  "description": "搜索企业内部知识库",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "要搜索的问题或关键词"
      }
    },
    "required": ["query"]
  }
}

Client 拿到这些工具定义后，可以把它们提供给模型，让模型在需要时选择调用。

工具发现的好处是：

Server 新增工具后，Client 可以动态发现
工具描述和参数 schema 由 Server 维护
不同 Host 可以复用同一个 MCP Server
Agent 代码不用频繁改动

但工具发现不代表所有工具都应该直接开放给模型。生产环境里还要根据用户权限、业务场景和风险等级做过滤。

比如普通用户只能看到查询类工具，管理员才能看到写入或删除类工具。

7、MCP如何调用工具？

MCP 工具调用大致分成几个步骤。

第一，Client 获取工具列表。

Client 先从 MCP Server 获取可用工具，以及每个工具的参数 schema。

第二，模型决定调用工具。

模型根据用户问题和工具描述，判断是否需要调用工具，以及调用哪个工具、传什么参数。

第三，Client 发起工具调用请求。

Client 按 MCP 协议把工具名和参数发送给 Server。

例如：

json

{
  "name": "search_docs",
  "arguments": {
    "query": "报销规则"
  }
}

第四，Server 执行真实逻辑。

Server 可能会去查数据库、调用 HTTP API、读取文件或访问企业系统。

第五，Server 返回结果。

结果返回给 Client，再由 Client 放回模型上下文，模型基于结果生成最终回答。

整体流程是：

text

用户输入
  ↓
模型选择工具
  ↓
MCP Client 调用工具
  ↓
MCP Server 执行工具
  ↓
工具结果返回模型
  ↓
模型生成最终回答

调用工具时一定要做参数校验和权限控制。MCP 提供了协议标准，但不代表可以跳过业务安全检查。尤其是写入、删除、发送消息这类有副作用的工具，最好加人工确认和审计日志。

8、MCP如何传递上下文？

MCP 传递上下文的方式主要有几类。

第一，通过工具参数传递。

这是最常见的方式。模型决定调用工具时，把必要信息放到 arguments 里。

json

{
  "query": "员工年假规则",
  "department": "研发部"
}

第二，通过 Resources 提供上下文。

MCP Server 可以暴露一些资源，比如文件、文档、数据库记录。Host 或 Client 可以读取这些资源，再把内容提供给模型。

第三，通过 Prompts 提供任务模板。

Server 可以提供提示词模板，让 Host 在特定任务里使用统一模板。

第四，通过会话状态或外部存储传递。

有些上下文不适合每次都放进工具参数，比如用户身份、权限、租户信息、会话 ID。这些通常由 Host 或业务系统管理，调用工具时再由 Server 做校验。

上下文传递时要注意两点。

第一，不要传太多。

MCP 能传上下文，不代表要把所有历史记录都传给工具。工具需要什么就传什么。

第二，要处理权限。

用户能看到什么资源、能调用什么工具，必须在 Host、Client 或 Server 侧做控制，不能只依赖模型自觉。

在 Agent 系统里，比较常见的方式是：

text

用户问题和会话上下文给模型
工具所需字段作为 arguments 传给 MCP Server
用户身份和权限由运行环境注入或校验

9、如何开发一个MCP Server？

开发 MCP Server，本质上是把已有系统能力包装成 MCP 标准能力。

一般步骤如下。

第一，确定要暴露哪些能力。

先想清楚这个 Server 是做什么的。比如知识库 Server 可以提供搜索文档、读取文档详情；数据库 Server 可以提供查看表结构、执行只读查询。

不要一开始就暴露太多工具，尤其是删除、写入、执行命令这类高风险能力。

第二，定义工具名称和描述。

工具名称要清楚，描述要说明什么时候用、什么时候不要用。

例如：

text

search_docs：搜索企业知识库。仅用于回答内部文档、制度、产品说明相关问题。

第三，定义输入参数 schema。

参数要明确类型、必填项和含义。

python

from pydantic import BaseModel, Field

class SearchDocsInput(BaseModel):
    query: str = Field(description="要搜索的问题或关键词")
    top_k: int = Field(default=5, description="返回结果数量")

第四，实现工具逻辑。

工具内部可以调用数据库、HTTP API、搜索服务或本地文件系统。

第五，增加权限、限流和审计。

不要因为接入 MCP 就忽略安全。生产环境里要记录谁调用了什么工具、参数是什么、结果是否成功。

第六，选择通信方式。

本地工具可以用 stdio，远程服务可以用 HTTP/SSE。

一个简单 MCP Server 的思路如下：

python

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("docs-server")

@mcp.tool()
def search_docs(query: str, top_k: int = 5) -> str:
    """搜索企业知识库。"""
    return f"搜索 {query}，返回前 {top_k} 条结果"

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

真实项目里，还要补上日志、异常处理、参数校验、权限控制和超时设置。

如果要接入 LangChain v1.0 或 LangGraph v1.0，通常会让应用侧作为 MCP Client 获取工具列表，再把 MCP 工具适配成 LangChain tools，交给 create_agent 或 LangGraph 的 ToolNode 使用。

10、MCP相比传统API有什么优势？

MCP 相比传统 API，最大的优势是更适合 AI 应用和 Agent 场景。

传统 API 主要是给程序员调用的。接口文档写给人看，调用逻辑写在代码里。模型要使用这些 API，需要开发者手动把 API 包装成工具，并写好 schema、description 和调用逻辑。

MCP 则把这些能力标准化了。

它的优势主要有几个。

第一，工具可复用。

同一个 MCP Server 可以被不同 Host 使用，比如桌面助手、IDE、企业 Agent 平台，不需要每个平台重新接一次。

第二，动态发现能力。

Client 可以通过协议发现 Server 提供的工具、资源和提示词，而不是所有工具都写死在代码里。

第三，更贴近模型使用方式。

MCP 工具天然带有名称、描述和参数 schema，更容易交给模型做工具选择。

第四，统一上下文接入。

除了工具，MCP 还支持 Resources 和 Prompts，可以把外部上下文以更标准的方式提供给模型应用。

第五，生态更容易扩展。

不同系统只要实现 MCP Server，就能接入支持 MCP 的 Host。对企业内部工具整合很有价值。

第六，安全治理更集中。

工具通过 Server 暴露后，可以在 Server 侧集中做权限、审计、限流和确认机制。

不过 MCP 不是用来替代所有 API 的。底层业务系统仍然可以是传统 API。MCP 更像是在 AI 应用和传统系统之间加了一层标准适配：

text

AI Agent / Host
  ↓ MCP
MCP Server
  ↓ HTTP / SDK / SQL
传统业务系统

在 LangChain 和 LangGraph 项目中也是类似。LangChain / LangGraph 负责编排 Agent 流程，MCP 负责把外部工具和上下文标准化接进来。两者不是替代关系，而是可以配合使用。

11 MCP面试题 ​

1、什么是MCP？ ​

2、MCP解决了什么问题？ ​

3、MCP和Function Calling有什么区别？ ​

4、MCP协议核心组成有哪些？ ​

5、MCP Client和MCP Server是什么？ ​

6、MCP如何发现工具？ ​

7、MCP如何调用工具？ ​

8、MCP如何传递上下文？ ​

9、如何开发一个MCP Server？ ​

10、MCP相比传统API有什么优势？ ​

11 MCP面试题

1、什么是MCP？

2、MCP解决了什么问题？

3、MCP和Function Calling有什么区别？

4、MCP协议核心组成有哪些？

5、MCP Client和MCP Server是什么？

6、MCP如何发现工具？

7、MCP如何调用工具？

8、MCP如何传递上下文？

9、如何开发一个MCP Server？

10、MCP相比传统API有什么优势？