AI Agent的工具困境

想象一下这个场景：你正在搭建一个 AI Agent 程序。LLM 大模型负责推理决策，一切都很美好。直到有一天你想让 Agent 调用一个用 Python 写的数据处理脚本，或者一个用 Java 写的公司级 API 服务。说起来，

"等等。我的 Agent 是 Node.js 写的啊！" 你挠着头说，

再想象另一个场景：你写了一个非常好用的工具函数，想在多个 Agent 项目中复用。结果发现每个项目都要 copy 一遍代码，改得面目全非。话说回来，

"能不能让工具独立出来谁想用就用？" 你开始思考，

这就是很多 AI 开发者都会遇到的“工具困境”

1. 工具与 LLM 强耦合工具代码必须和 Agent 代码在同一个进程里难以复用。
2. 跨语言调用困难Node.js 的 Agent 怎么调用 Python / Rust / Java 写的工具？
3. 通信方式混乱有的用 HTTP。有的用进程间通信，没有统一标准。

就在这时MCP 协议出现了——它就像一座桥梁。让 AI Agent 能够优雅地跨越进程边界，调用任何语言写的工具。

定义的观点是，Model Context Protocol

MCP 的全称是 Model Context Protocol从名字就能看出它的主要使命：给 AI 模型 上下文让模型能做的更多、知道的更多。

但它不是简单的 API 调用。Fetch 调用是拿数据，而 MCP 调用是 能力。这是本质区别，

主要特点

MCP 最大的特点就是跨进程调用。从简单讲来看，

• 本地跨进程通过 stdio实现进程间通信。想象一下一个进程启动另一个子进程，它们之间通过键盘输入和控制台输出来对话。
• 远程跨进程通过 HTTP 实现远程通信。MCP 协议负责管理 HTTP 服务器，客户端通过 HTTP 请求调用工具。

┌─────────────────────────────────────────────────────────────┐
│ AI Agent │
│ │
└─────────────────────────┬───────────────────────────────────┘
│ ┌───────────────┴───────────────┐
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Stdio 传输 │ │ HTTP 传输 │
│ │ │ │
└────────┬────────┘ └────────┬────────┘
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ MCP Server A │ │ MCP Server B │
│ │ │ │
└─────────────────┘ └─────────────────┘

架构模式

MCP 采用经典的客户端‑服务器模式

1. MCP Server工具提供者，注册并暴露工具供外部调用。
2. MCP Client工具使用者，连接到 Server 并调用工具。
3. Transport传输层，负责协议通信。

AI Agent 作为 MCP 客户端。可以配置多个 MCP Server，实现灵活的工具调用。

说到实战，从零搭建 MCP Server

Theory is done。now let's roll up our sleeves and build a real MCP server that implements a simple “query_user” tool.

项目初始化

Create project and install required dependencies:

mkdir mcp-demo && cd mcp-demo
pnpm init -y
pnpm add @modelcontextprotocol/sdk zod dotenv

关键依赖说明：

• @modelcontextprotocol/sdk: MCP 协议主要 SDK。
• Zod: TypeScript‑first schema 验证库，用来校验参数类型。
• Ddotenv: 环境变量管理。

McpServer 主要 API 解析

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';const server = new McpServer({
至于name。'my-mcp-server',version: '1.0.0',});

The two options are:

• name: string : Server identifier – clients reference this name when y want to call tools.
• : Version number for compatibility management.

工具注册与参数验证

server.tool(
'query_user','查询数据库中的使用者信息。输入使用者ID,返回该使用者的详细信息。',{
再看userId，z.string.describe。},async => {
// 实际业务逻辑放这里…，}
);

handler 实现业务逻辑 Business logic implementation. Oops we need correct table markup: But we should provide correct HTML table. Let's rewrite correctly:

参数名	类型	说明
Name	唯一标识符 Unique identifier for tool.	LLM 用来决定是否调用此工具 Used by LLM to decide wher to invoke.
Description	自然语言描述 Human‑readable description.	帮助 LLM 理解功能 Helps LLM understand purpose.	结构化校验 Structured validation.自动生成文档并在运行时检查 Generates docs & validates at runtime.

Name / 参数名		Description / 说明
Name	- 唯一标识符 Unique identifier for tool.	- LLM 用来决定是否调用此工具 Used by LLM to decide wher to invoke.
Description	- 自然语言描述 Human‑readable description.	- 帮助 LLM 理解功能 Helps LLM understand purpose.
`parameters`	- 对象结构化校验 Structured validation of arguments.	- 自动生成文档并在运行时检查 Generates docs & validates at runtime.
`handler`	- 异步业务实现函数 Async business logic function.	- 接收已验证参数并返回符合协议格式的数据 Receives validated args and returns protocol‑compliant result.

Continue...

This is **“工具困境”** that many AI 开发者都会遇到：

1. 工具与 LLM 强耦合：  工具代码必须和 Agent 同处于同一进程里导致复用成本极高；

跨语言调用困难： Node.js 的 Agent 想调 Python / Rust / Java 编写的业务逻辑时几乎无路可走；

通信方式混乱： 老实说，有人选 HTTP，有人选 IPC，没有统一标准导致维护噩梦。

Tool Name

Description

Language

Transport

query_user

查询使用者信息

Node.js/TS

Stdio/HTTP

true...

format,‘l d F Y H:i’);，>

,

---

Lorem Ipsum dolor sit amet consectetur adipisicing elit. 。

---

。

---