第1章 MCP协议基础

1. MCP协议基础：从零开始理解这个“智能体操作系统”

说实话，我第一次接触MCP协议的时候，脑子里冒出的第一个念头是——这不就是AI世界的USB接口吗？

你想想看，我们平时用电脑，插个U盘就能读写文件，插个打印机就能打印文档。那AI模型呢？它怎么跟外部世界打交道？怎么访问你的数据库？怎么调用你的API？

嗯，MCP就是干这个的。它全称叫Model Context Protocol，说白了就是给大语言模型装了一个“万能插头”。

1.1 为什么需要MCP？

我在做AI安全研究的时候，经常遇到一个尴尬的场景：客户说“让AI帮我查一下数据库里的订单”。传统做法是什么？写一堆定制化的API接口，每个接口都要单独调试、单独鉴权、单独处理错误。累不累？累死了。

MCP的出现，就是为了解决这个“万国接口”的问题。它定义了一套标准化的通信方式，让AI模型可以像人一样，自然地调用各种工具和数据源。

核心痛点： 没有MCP之前，每个AI应用都是“孤岛”。你想让AI访问数据库、调用API、读写文件，得自己写一堆胶水代码。MCP把这些统一了。

1.2 三个核心角色：Host、Client、Server

MCP的架构其实不复杂，就三个角色。我习惯用“餐厅”来打比方：

Host（主机） —— 就是“顾客”。它发起请求，比如“帮我查一下今天的销售数据”。Host通常是AI应用本身，比如Claude Desktop、VS Code插件、或者你自建的AI平台。
Client（客户端） —— 这是“服务员”。它负责把顾客的需求转达给后厨，再把做好的菜端回来。在MCP里，Client负责建立连接、管理会话、转发消息。
Server（服务器） —— 这是“后厨”。它真正干活，比如连接数据库、调用API、读写文件。Server暴露的是“工具”（Tools）和“资源”（Resources）。

我记得有一次做渗透测试，客户问：“MCP Server会不会成为新的攻击面？” 我的回答是：会，而且很严重。因为Server直接操作底层资源，一旦被攻破，数据库、文件系统全暴露了。这个我们后面会详细讲。

1.3 协议架构与通信模型

MCP的通信模型，说白了就是“JSON-RPC over 传输层”。

它支持两种传输方式：

传输方式	适用场景	特点
stdio（标准输入输出）	本地进程间通信	简单、轻量、适合单机部署
SSE（Server-Sent Events）	远程网络通信	支持流式响应、适合分布式场景

我个人更关注stdio模式，为什么？因为本地通信更容易被hook和劫持。你想想看，如果攻击者能注入恶意进程，截获stdio流，那整个MCP通信就裸奔了。

通信流程大致是这样的：

Host发起连接请求
Client与Server建立传输通道
双方交换能力声明（Capabilities）
Host通过Client调用Server提供的工具或资源
Server执行操作并返回结果
连接关闭或保持长连接

小提示： 能力声明这一步很关键。Server会告诉Client“我能干什么”，比如“我能查数据库”、“我能发邮件”。如果Server声明了太多能力，攻击面就大了。我建议做安全审计时，先看能力声明。

1.4 核心数据结构

MCP的消息格式是JSON-RPC 2.0。一个典型的请求长这样：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT * FROM users"
    }
  }
}

响应呢？

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "查询结果：共10条记录..."
      }
    ]
  }
}

嗯，这里有个坑。你看params里直接传了SQL语句。如果Server端没有做参数校验，这就是SQL注入的温床。我曾经在某个MCP实现里发现，Server直接把arguments拼接到SQL里执行了——典型的注入漏洞。

1.5 知识体系总览

下面这张图是我自己画的，把MCP的核心脉络理清楚了。你一看就明白：

1.6 实际项目中的体会

我去年帮一个金融客户做MCP安全审计。他们的MCP Server暴露了三个工具：query_account、transfer_funds、send_notification。看起来挺正常对吧？

但问题出在哪？出在query_account的参数里。它接受一个user_id参数，但Server端没有校验当前Host是否有权限查这个用户的数据。结果就是：Host A可以查Host B的账户信息。这就是典型的“越权访问”。

注意： MCP本身不提供鉴权机制。鉴权完全靠Server自己实现。很多开发者会忽略这一点，觉得“反正Client是可信的”。大错特错！Client可以被劫持，Host可以被伪造。

所以我的建议是：在设计MCP Server时，每个工具都要做独立的权限校验。不要相信任何传入的上下文信息，除非你亲自验证过。

1.7 小结

MCP协议说白了就是一套“AI万能接口”。它用三个角色（Host、Client、Server）和一套JSON-RPC通信机制，让AI模型能跟外部世界自由交互。

但便利的背后是风险。作为安全研究员，我每次看到MCP的实现，第一反应就是：这个Server暴露了哪些工具？参数有没有校验？传输层有没有加密？

嗯，这些就是我们后面要深入挖掘的内容。先把基础打牢，后面才能挖得深。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

1. MCP协议基础：从零开始理解这个“智能体操作系统”

1.1 为什么需要MCP？

1.2 三个核心角色：Host、Client、Server

1.3 协议架构与通信模型

1.4 核心数据结构

1.5 知识体系总览

1.6 实际项目中的体会

1.7 小结