📒 学霸笔记：12｜终极扩展：深入 MCP 服务器，将 AI 连接到任何内外部系统

Top Student Notes: 12 | Ultimate Extension: Deep Dive into MCP Servers to Connect AI to Any Internal or External System

课程 / Course: AI 原生开发工作流实战 / AI-Native Development Workflow in Practice
讲师 / Instructor: Tony Bai
章节 / Chapter: 12
主题 / Topic: MCP、Model Context Protocol、Host/Client/Server、Tools/Resources/Prompts、本地 stdio 服务器、远程 HTTP MCP、GitHub MCP Server、AI 连接外部系统

一、这一讲在解决什么问题？

What Problem Does This Lecture Solve?

前面的课程，我们已经不断增强 Claude Code：

@：看上下文
!：跑命令
CLAUDE.md：记规则
Slash Commands：封装工作流
Hooks：事件驱动自动化
Permissions / Sandbox / Checkpointing：建立安全边界与可反悔能力

但到这里为止，AI 的能力大多仍被限制在：

Claude Code 内置工具所能覆盖的本地世界里。

也就是说，它擅长：

读写文件
执行 shell
修改代码
本地分析

但如果你想让它做下面这些事呢？

查公司内部知识库
操作 Jira 工单
创建 GitHub Issue / PR
访问 Figma 设计稿
调内部 API 网关
查询监控、告警、数据库、工单系统

这些都已经超出“本地工具”的边界。

所以这一讲解决的问题是：

如何让 AI 不再只会操作本地工程，而是能以结构化、安全、标准化的方式连接任何外部系统。

Claude Code 给出的答案就是：

MCP（Model Context Protocol）服务器

二、本讲核心结论

Core Conclusion of This Lecture

一句话总结

MCP 是为 AI Agent 设计的标准化能力扩展协议，它把外部系统包装成 AI 可发现、可调用、可治理的工具接口，从而让 AI 真正连接万物。

三、为什么 Bash + curl 还不够？

Why Aren’t Bash + curl Enough?

这是这一讲最重要的起点。

很多人会直觉地想：

“既然 Claude Code 已经能跑 Bash，那让 AI 直接 curl 调 API 不就行了？”

Tony 的回答很明确：

在简单场景下也许可以，但在严肃工程实践里，这种方式非常脆弱。

1. 脆弱性

Fragility

如果靠 curl，你得把一大堆 API 细节塞进 Prompt：

URL
请求头
JSON body
参数格式
返回结构

这会导致：

Prompt 又长又脆
出错概率高
AI 容易误拼参数或结构

2. 安全性差

Poor Security

如果 API 需要鉴权，你就得把：

TOKEN
API_KEY
Secret

暴露在 Prompt 或命令里。

这会带来很严重的风险：

出现在对话历史中
容易被误记录
不利于团队共享与审计

3. 无状态

Statelessness

很多外部系统交互不是一步搞定的，例如：

OAuth 认证
分页查询
多步提交
长连接会话

curl 很难自然管理这种状态。

4. 发现性差

Poor Discoverability

AI 并不知道你的 API 能做什么。

它不知道：

有哪些 endpoint
各自参数是什么
哪个工具适合做什么事

除非你人工把这些信息一次次塞给它。

学霸理解

所以问题的本质不是“AI 能不能访问 API”，而是：

如何让 AI 以一种结构化、安全、具备能力发现机制的方式访问 API。

MCP 就是专门为这个问题设计的。

四、MCP 到底是什么？

What Is MCP?

Tony 的定义非常关键：

MCP 不是某个具体工具，而是一套开放的、为 AI Agent 设计的 RPC 协议。

关键词拆解

开放协议

不是某厂商私有黑盒，而是一个标准化接口思想。

为 AI Agent 设计

不是普通 API 协议，而是面向：

大模型调用
工具发现
参数理解
安全接入
会话协作

RPC 协议

本质上是在说：

AI 不再“乱拼命令”，而是像调用远程函数一样调用外部能力。

一句话理解

MCP 就是在 AI 和外部系统之间加了一层标准化能力抽象。

五、MCP 解决了什么核心问题？

What Core Problems Does MCP Solve?

1. 服务发现

服务器会主动告诉 Claude Code：

我有哪些工具
每个工具叫什么
参数结构是什么
工具的用途是什么

于是 AI 不再靠猜，而是“知道自己能调用什么”。

2. 认证解耦

Token 不再出现在 Prompt 中。
认证配置在 Claude Code 主机侧完成。

这意味着：

AI 不直接接触秘钥
密钥管理更安全
更适合团队配置和生产环境

3. 结构化调用

不是写原始 curl，而是：

明确工具名
明确参数 schema
明确返回结果格式

这让 AI 更容易可靠使用。

4. 能力命名空间化

不同服务器的工具会自动带前缀，避免冲突。

例如：

mcp__github__create_issue
mcp__hello__greet

这样多个服务可以共存。

5. 可治理性更强

因为工具是显式注册的，权限也能细化配置，整个外部能力接入更可控。

六、MCP 的三个核心角色

The Three Core Roles in MCP

这一讲最重要的理论结构就是：

Host
Client
Server

必须分清楚。

七、Host：总指挥与协调者

Host: The Commander and Coordinator

在 Claude Code 体系里：

Claude Code 本身就是 Host。

Host 的职责

1. 创建和管理客户端实例

每连接一个 MCP Server，Host 都会管理对应连接。

2. 执行安全策略

例如：

权限确认
工具调用边界
用户批准流程

3. 作为 AI 模型与外部世界的桥梁

Host 负责把：

模型的工具调用意图
转换成具体协议请求
再把结果带回来

学霸理解

Host 相当于：

AI 外部能力总调度中心

八、Server：能力提供方

Server: The Capability Provider

Server 是一个独立程序，可以是：

本地脚本
本地可执行程序
云端 HTTP 服务
公司内部 API 网关封装器

它的职责

就是向 Host 暴露自己的能力。

根据 MCP 规范，Server 可以提供三类东西：

Tools
Resources
Prompts

这三个一定要记住。

九、Client：专线连接器

Client: The Dedicated Connector

Client 通常对用户不可见。
它是 Host 内部创建的一个组件。

它的作用

为某个特定 Server 建立一条一对一连接
负责协议协商
负责消息路由
负责会话状态维护

学霸理解

如果说：

Host 是总控台
Server 是能力站点

那么：

Client 就是总控台到每个能力站点的专属连线器。

十、MCP 的三类能力：Tools / Resources / Prompts

The Three Capability Types in MCP

这是本讲最值得背诵的结构。

十一、Tools：AI 可以执行的动作

Tools: Actions AI Can Execute

这是最核心的一类。

例如：

create_issue
list_prs
search_code
query_metrics
create_ticket

本质上就是：

AI 可调用的远程动作函数

特点

有名字
有参数 schema
有明确用途
有结构化结果

十二、Resources：AI 可以引用的数据

Resources: Data AI Can Reference

这类能力更偏“上下文读取”。

例如：

某个 issue 的内容
某篇知识库文档
某条监控曲线
某个配置项
某个设计稿对象

价值

Resources 使外部世界不仅能“被调用”，也能“被引用为上下文”。

Tony 举例：

@github:issue://123

这说明外部资源也可以像文件一样进入 AI 上下文体系。

十三、Prompts：服务器提供的工作流模板

Prompts: Workflow Templates Provided by the Server

这是 MCP 的一个很容易被忽略、但非常高级的能力。

服务器不只提供动作，还能提供：

已经封装好的工作流提示模板

然后 Claude Code 可以把它们自动转换为 Slash Commands。

价值

这意味着服务器作者不仅在暴露 API，还在暴露：

最佳实践
最优 Prompt 模板
高频工作流入口

学霸理解

这相当于：

MCP Server 不只是能力提供方，还是“能力使用方法论”的打包者。

十四、MCP 的工作流程

The MCP Workflow

Tony 给出的更精确描述是：

Host（Claude Code）接收到模型的工具调用意图后，通过某个 Server 对应的 Client，把请求按 MCP 协议发送给 Server；Server 执行业务逻辑后返回结果，再由 Host 呈现给用户或回传给模型。

简化成流程

用户提需求
    ↓
大模型决定需要调用某个 MCP 工具
    ↓
Claude Code（Host）接收这个意图
    ↓
对应 Client 把调用翻译成 MCP 请求
    ↓
MCP Server 执行业务逻辑
    ↓
返回结果给 Client
    ↓
Claude Code 再交给模型或展示给用户

十五、MCP 的关键特性

Key Properties of MCP

1. 服务发现

Server 在连接时自我介绍：

有哪些工具
参数怎么传
能力范围是什么

2. 责任分离

模型：决定“调哪个工具”
Host/Client：负责协议和路由
Server：负责具体业务逻辑

3. 命名空间

Claude Code 会自动把工具名变成：

mcp__<server_name>__<tool_name>

例如：

mcp__github__create_issue
mcp__hello__greet

4. 认证解耦

Token 不给模型看，而由 Host 通过环境变量等方式注入。

这是非常重要的安全设计。

十六、MCP Server 的三种传输方式

Three Transport Types for MCP Servers

Claude Code 注册 MCP Server 时支持三种 transport。

1. `stdio`

用于本地运行的服务器，通过标准输入/输出通信。

适合：

本地脚本
本地自定义工具
轻量集成
实验与开发

2. `http`

用于远程 MCP 服务器。

适合：

SaaS 服务
公司内部网关
云端统一能力服务

3. `sse`

旧方式，已废弃或不推荐，知道即可。

十七、MCP 配置的三大 Scope

The Three Scopes for MCP Configuration

这一讲和之前配置体系保持一致，也有分层作用域概念。

1. `local`

默认作用域
适合：

临时实验
本地私测
不想提交 Git

2. `user`

适合：

个人私有工具
跨项目复用
不需要团队共享的长期能力

3. `project`

适合：

团队共享
项目级标准集成
希望提交到仓库的配置

最佳实践

Tony 的建议很好记：

团队共享 → project
个人长期使用 → user
临时测试 → local

十八、MCP 的管理命令

MCP Management Commands

Claude Code 提供：

claude mcp add
claude mcp add-json
claude mcp list
claude mcp get
claude mcp remove

另外在交互界面里还能用：

/mcp

查看服务器状态与能力列表。

十九、实战一：自己用 Go 写一个本地 stdio MCP Server

Practical Example 1: Build a Local stdio MCP Server in Go

这个实战非常重要，因为它让你真正触摸到协议层。

目标

写一个最简单的本地 MCP Server，提供一个工具：

greet

输入名字，返回一句问候。

这个例子的意义

不是为了问候本身，而是为了让你理解：

MCP Server 如何读取请求
如何响应 initialize
如何提供 tools/list
如何处理 tools/call

这就是 MCP 的最小闭环。

二十、这个 Go Server 的核心结构

Core Structure of the Go Server

Tony 给出的 Go 程序，本质上实现了一个标准的 JSON-RPC 风格 stdio 服务。

1. 主循环读取 stdin

服务器通过：

bufio.Scanner
从 os.Stdin 读取每一行 JSON 请求

2. 路由请求方法

根据 req.Method 分发到不同 handler：

initialize
tools/list
tools/call
notifications/initialized

3. `handleInitialize`

向 Claude Code “自我介绍”：

协议版本
自己支持哪些能力
serverInfo

4. `handleToolsList`

返回工具列表：

greet
描述
输入参数 schema

5. `handleToolCall`

处理具体工具调用：

看是否是 greet
读取 arguments.name
生成问候语
按 MCP 预期格式返回

学霸理解

这个例子本质上是在教你：

MCP Server = 一个能响应“初始化 / 列能力 / 调能力”的小型协议服务。

二十一、如何注册这个本地 Go Server？

How to Register This Local Go Server?

命令是：

claude mcp add --transport stdio hello -- go run ./hello-mcp-server.go

拆解理解

claude mcp add：添加服务器
--transport stdio：说明是本地 stdio 通信
hello：服务器名
--：后面是启动命令
go run ./hello-mcp-server.go：启动本地服务

为什么这个设计很优雅？

因为 Claude Code 不要求你手动先把服务跑起来。
它会在需要时自己启动这个进程，并通过 stdin/stdout 跟它对话。

二十二、如何验证服务器连通？

How to Verify Connectivity?

用：

claude mcp list

如果显示：

hello: go run ./hello-mcp-server.go - ✓ Connected

说明服务健康可用。

另外在 Claude Code 里还能通过：

/mcp

查看状态。

二十三、如何调用 MCP 工具？

How to Invoke an MCP Tool?

工具命名规则是：

mcp__<server_name>__<tool_name>

因此这里的工具名是：

mcp__hello__greet

你可以自然语言让 Claude 调用它。

这个实战真正让你学会了什么？

你真正掌握了完整闭环：

定义工具能力
注册服务器
发现能力
调用能力
返回结果

这就是你以后把任何本地脚本能力封装成 MCP 的基础。

二十四、实战二：连接远程 GitHub MCP Server

Practical Example 2: Connect to a Remote GitHub MCP Server

这是更接近真实企业使用场景的案例。

场景意义

现实中你更多会接的不是自己写的本地服务器，而是：

公司内部服务
SaaS 平台
第三方官方 MCP 服务

GitHub MCP Server 就是典型代表。

二十五、第一步：先解决认证

Step 1: Solve Authentication First

任何外部服务接入，认证永远是第一步。

这里使用的是：

GitHub Personal Access Token（PAT）

Tony 特别强调安全实践：

绝不能把 Token 硬编码进配置文件。

而应当：

export GITHUB_TOKEN="..."

放进环境变量中。

为什么这很重要？

因为这样：

配置可提交共享
但凭证不进仓库
每个成员用自己的 Token
更容易轮换和审计

二十六、第二步：用 `add-json` 注册远程 HTTP MCP

Step 2: Register the Remote HTTP MCP via `add-json`

命令是：

claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp/","headers":{"Authorization":"Bearer ${GITHUB_TOKEN}"}}' --scope project

拆解理解

add-json：直接传入完整 JSON 配置
github：服务器名
"type":"http"：远程 HTTP MCP
"url"：GitHub MCP 服务端点
"headers"：给所有请求附加 Authorization
${GITHUB_TOKEN}：从环境变量读取
--scope project：项目级共享配置

生成结果

Claude Code 会在项目里写出：

.mcp.json

这个文件可以提交到仓库中，供团队共享。

二十七、`.mcp.json` 的意义

Why `.mcp.json` Matters

这个文件本质上是：

项目级 MCP 集成清单

它记录：

接了哪些服务器
用什么 transport
请求地址是什么
头部如何配置

这让 MCP 接入开始具有：

可复用性
可共享性
可团队协作性

二十八、第三步：检查服务状态和能力列表

Step 3: Check Server Status and Tool Inventory

可以通过：

claude mcp list

或者：

/mcp

查看。

价值

你不只是确认“连上了没有”，还可以看到：

服务名称
transport 类型
可用工具列表
整体能力范围

这就是服务发现的可视化体现。

二十九、第四步：用自然语言直接操作 GitHub

Step 4: Operate GitHub with Natural Language

这是最震撼的部分。

你可以说：

创建一个 issue
给 issue 加评论
关闭该 issue

Claude Code 会：

理解你的目标
发现需要用 GitHub MCP 工具
提议调用 mcp__github__create_issue
经你批准后执行
返回结果

本质变化

以前要做这些你得：

打开浏览器
点界面
或自己写 GitHub API 请求

现在变成：

自然语言 → AI → 结构化工具调用 → GitHub 真实变更

这就是 MCP 把 AI 从“本地助手”升级为“生态中枢”的关键一步。

三十、MCP 的高级用法：Prompts 变 Slash Commands

Advanced MCP Usage: Turning Prompts into Slash Commands

这是很高级但非常有价值的一点。

如果某个 MCP 服务器还提供了 Prompts，Claude Code 可以自动把它们变成：

/mcp__<server_name>__<prompt_name>

形式的 Slash Commands。

为什么这很强？

因为这意味着：

服务器作者把复杂 Prompt 模板预先写好了
用户不需要理解底层工具细节
只需要执行一个简单命令

例如：

/mcp__github__list_prs

就可以直接触发一个优化好的工作流。

学霸理解

这相当于：

MCP 不只给你 API，还给你“最佳实践入口”。

三十一、这一讲的真正方法论价值

The Real Methodological Value of This Lecture

这一讲真正厉害的地方，不只是教你接 GitHub，而是完成了一次边界突破：

AI 的能力边界，从本地工程系统，扩展到整个技术生态系统。

以前的 AI 能力边界

文件
命令
本地代码
本地环境

现在的 AI 能力边界

云服务
工单系统
仓库平台
知识库
监控系统
内部平台
设计平台
任何 API 能封装成 MCP 的地方

所以这讲最本质的一句话是

MCP 让 AI 不再只是代码助手，而是自动化中枢。

三十二、这一讲和前面课程的关系

How This Lecture Connects to Earlier Lessons

前面课程一直在做三件事：

让 AI 看见项目
让 AI 遵守规则
让 AI 在本地环境中可靠执行

12 讲开始补上第四件事：

让 AI 看见并操作项目外的世界。

串联起来就是

@ / !：本地感知与行动
CLAUDE.md / constitution.md：本地规则与原则
Slash Commands / Hooks：本地流程自动化
MCP：外部能力接入与生态联动

三十三、哪些内部系统最适合做成 MCP？

Which Internal Systems Are Best Turned into MCP Servers?

Tony 的思考题其实是在训练你建立“平台化扩展”思维。

典型适合 MCP 化的内部系统包括：

1. 知识库系统

例如：

FAQ
技术文档
代码片段库
架构决策记录

可暴露工具

search_docs
get_snippet
get_arch_decision

2. 监控系统

例如：

服务 QPS
错误率
延迟
告警历史

可暴露工具

query_metrics
get_alerts
get_service_status

3. 工单系统

例如：

Jira
内部 ticket 平台

可暴露工具

create_ticket
update_ticket
link_incident

4. 发布平台

可暴露工具

create_release
query_deploy_status
rollback_release

5. 设计系统

例如：

Figma 封装接口

可暴露工具

get_component_spec
list_design_tokens
export_frame

三十四、使用 MCP 的设计原则

Design Principles for Using MCP

原则 1：把稳定、高价值、结构化的外部能力做成 MCP

不是所有 API 都要接。
优先接高频、关键、稳定的能力。

原则 2：认证一定与 Prompt 解耦

永远不要在 Prompt 里塞秘钥。
通过环境变量或主机侧配置处理。

原则 3：团队共享的能力优先放 `project scope`

形成可复用的工程平台能力。

原则 4：把复杂操作尽量抽象成明确工具，而不是让 AI 拼原始请求

MCP 的价值就在于“结构化与发现性”。

原则 5：如果服务器能提供 Prompts，就进一步降低使用门槛

不仅暴露能力，还暴露最佳实践入口。

三十五、本讲知识结构图

Knowledge Structure of This Lecture

Claude Code 内置工具能力有限
        ↓
需要连接外部世界
        ↓
直接 curl 不够
├── 脆弱
├── 不安全
├── 无状态
└── 不可发现
        ↓
MCP
= 为 AI Agent 设计的标准化 RPC 协议
        ↓
三大角色
├── Host（Claude Code）
├── Client（内部连接器）
└── Server（能力提供者）
        ↓
Server 可暴露三类能力
├── Tools
├── Resources
└── Prompts
        ↓
三种 transport
├── stdio（本地）
├── http（远程）
└── sse（旧）
        ↓
三种 scope
├── local
├── user
└── project
        ↓
实战一：Go 本地 stdio MCP Server
├── initialize
├── tools/list
└── tools/call
        ↓
实战二：远程 GitHub MCP Server
├── PAT 认证
├── 环境变量
├── add-json 注册
└── 自然语言操作 GitHub
        ↓
最终结果
AI 从本地助手进化为连接整个技术生态的自动化中枢

三十六、学霸速记表

Quick Revision Table

知识点	结论
MCP 是什么	为 AI Agent 设计的标准化 RPC 协议
为什么不用 curl 代替	脆弱、不安全、无状态、不可发现
Host	Claude Code，本质是总调度者
Client	Host 内部创建的专属连接器
Server	能力提供方，本地或远程服务
Server 可暴露什么	Tools / Resources / Prompts
工具命名空间	`mcp__<server>__<tool>`
认证方式	由 Host 侧通过环境变量等注入，不暴露给模型
transport	`stdio` / `http` / `sse`
scope	`local` / `user` / `project`
本地 MCP 实战重点	实现 `initialize`、`tools/list`、`tools/call`
远程 MCP 实战重点	Token 环境变量、HTTP 注册、自然语言调用
高级用法	Prompts 自动转成 Slash Commands
本讲最终意义	让 AI 从本地工具升级为生态系统自动化中枢

三十七、学霸自检题

Self-Check Questions

基础题

MCP 为什么比让 AI 直接 curl API 更适合生产场景？
MCP 中 Host、Client、Server 分别是谁、做什么？
MCP Server 可以暴露哪三类能力？

进阶题

为什么说 MCP 的关键价值之一是“服务发现”？
为什么认证必须和 Prompt 解耦？
本地 stdio MCP 和远程 http MCP 的主要区别是什么？

思辨题

你所在团队最值得先做成 MCP Server 的内部系统是什么？为什么？
你会把哪些高频 API 动作封装成 Tools，哪些信息暴露成 Resources？
如果你要做一个“线上故障排查 MCP Server”，它最应该暴露哪些工具？

三十八、学霸总结

Top-Student Summary

这一讲讲的是 Claude Code 乃至 AI Agent 扩展能力的终极形态：MCP（Model Context Protocol）。
它解决的核心问题是：

如何让 AI 安全、结构化、标准化地连接任何内外部系统，而不再局限于本地文件和 Shell 命令。

Tony 首先说明了为什么直接用 curl 调 API 不足以支撑严肃工程实践：
这种方式存在脆弱性强、安全性差、状态管理困难、能力不可发现等问题。而 MCP 的设计，正是为了解决这些缺陷。它不是某个具体工具，而是一套面向 AI Agent 的标准化 RPC 协议，在 AI 与外部系统之间建立了一层安全、抽象、可发现的能力桥梁。

理解 MCP 的关键在于三个角色：

Host：Claude Code，本质是总调度者和安全边界执行者
Client：Host 内部为每个 Server 创建的专属连接器
Server：能力提供方，可以是本地程序，也可以是远程服务

其中 Server 可以暴露三类核心能力：

Tools：可执行动作
Resources：可引用数据
Prompts：可封装工作流模板

在使用层面，Claude Code 支持通过 stdio 连接本地服务，通过 http 连接远程服务，并通过 local / user / project 三种 scope 管理配置的可见范围和共享级别。

两个实战把理论落到了地面：

用 Go 编写本地 stdio MCP Server
让你理解一个最小 MCP 服务器如何响应 initialize、tools/list 和 tools/call，完成从定义能力到调用能力的闭环。
连接远程 GitHub MCP Server
让你掌握在真实场景中使用环境变量安全管理 Token、通过 add-json 注册远程服务、并最终用自然语言驱动 GitHub 操作的完整过程。

最后，Tony 还强调了 MCP 的高级能力：服务器暴露的 Prompts 可以自动转换为 Slash Commands，从而把复杂工作流变成简单可调用命令。这意味着 MCP 不只是连接 API，更是在传递“能力的最佳使用方式”。

因此，这一讲最核心的认知升级是：

AI 的能力边界第一次真正突破本地工程环境，扩展到了整个技术生态系统。

从这一刻开始，AI 不再只是代码生成器或本地助手，而开始成为：

连接团队工具链、内部平台、SaaS 服务和知识系统的自动化中枢。

三十九、一句话记忆

One-Sentence Memory Hook

MCP 的本质，是把外部系统包装成 AI 可发现、可调用、可治理的标准工具接口，让 AI 从“会改本地代码”进化为“能连接整个技术生态”的自动化中枢。

【AI生成】学霸笔记：12｜｜终极扩展：深入 MCP 服务器，将 AI 连接到任何内外部系统

📒 学霸笔记：12｜终极扩展：深入 MCP 服务器，将 AI 连接到任何内外部系统

Top Student Notes: 12 | Ultimate Extension: Deep Dive into MCP Servers to Connect AI to Any Internal or External System

一、这一讲在解决什么问题？

What Problem Does This Lecture Solve?

二、本讲核心结论

Core Conclusion of This Lecture

一句话总结

三、为什么 Bash + curl 还不够？

Why Aren’t Bash + curl Enough?

1. 脆弱性

Fragility

2. 安全性差

Poor Security

3. 无状态

Statelessness

4. 发现性差

Poor Discoverability

学霸理解

四、MCP 到底是什么？

What Is MCP?

关键词拆解

开放协议

为 AI Agent 设计

RPC 协议

一句话理解

五、MCP 解决了什么核心问题？

What Core Problems Does MCP Solve?

1. 服务发现

2. 认证解耦

3. 结构化调用

4. 能力命名空间化

5. 可治理性更强

六、MCP 的三个核心角色

The Three Core Roles in MCP

七、Host：总指挥与协调者

Host: The Commander and Coordinator

Host 的职责

1. 创建和管理客户端实例

2. 执行安全策略

3. 作为 AI 模型与外部世界的桥梁

学霸理解

八、Server：能力提供方

Server: The Capability Provider

它的职责

九、Client：专线连接器

Client: The Dedicated Connector

它的作用

学霸理解

十、MCP 的三类能力：Tools / Resources / Prompts

The Three Capability Types in MCP

十一、Tools：AI 可以执行的动作

Tools: Actions AI Can Execute

特点

十二、Resources：AI 可以引用的数据

Resources: Data AI Can Reference

价值

十三、Prompts：服务器提供的工作流模板

Prompts: Workflow Templates Provided by the Server

价值

学霸理解

十四、MCP 的工作流程

The MCP Workflow

简化成流程

十五、MCP 的关键特性

Key Properties of MCP

1. 服务发现

2. 责任分离

3. 命名空间

4. 认证解耦

十六、MCP Server 的三种传输方式

Three Transport Types for MCP Servers

1. stdio

2. http

3. sse

十七、MCP 配置的三大 Scope

The Three Scopes for MCP Configuration

1. local

2. user

3. project

1. `stdio`

2. `http`

3. `sse`

1. `local`

2. `user`

3. `project`

3. `handleInitialize`

4. `handleToolsList`

5. `handleToolCall`

二十六、第二步：用 `add-json` 注册远程 HTTP MCP

Step 2: Register the Remote HTTP MCP via `add-json`

二十七、`.mcp.json` 的意义

Why `.mcp.json` Matters