在FastMCP里，mount、import_server、as_proxy都是把多个 MCP Server 组合/复用的方式，但目的、层级和行为不同。可以把它们理解成三种“接入方式”。
下面用直觉 + 对比 + 示例帮你一次分清 👇
一句话先区分
| 方法 | 核心作用 | 像什么 |
|---|---|---|
mount | 把另一个 MCP Server挂到路径下 | Web 框架里的router.mount() |
import_server | 合并另一个 Server 的 tools/resources | 代码层面的import * |
as_proxy | 把 FastMCP 当成纯转发代理 | 反向代理 / 网关 |
一、mount——「路径级挂载（子服务）」
概念
把一个完整的 MCP Server挂到当前 Server 的某个namespace / 路径下
两个 server逻辑上仍然独立
tool 名字会带前缀
特点
✅ 保留原 server 的结构
✅ 清晰的命名空间隔离
❌ 调用时路径更长
示例
main = FastMCP("main") files = FastMCP("files") @files.tool() def read_file(path: str) -> str: ... main.mount("files", files)调用时（概念上）
{ "tool": "files.read_file", "arguments": { "path": "a.txt" } }适合场景
多模块 / 微服务式 MCP
不想 tool 名冲突
想清楚地区分“子系统”
👉最像 FastAPI 的app.mount("/files", app2)
二、import_server——「直接合并能力（扁平化）」
概念
把另一个 MCP Server 的tools / resources / prompts
直接拷贝进当前 server对 LLM 来说，像是同一个 server
特点
✅ tool 名直接可用（无前缀）
✅ 对模型最友好
❌ 可能产生命名冲突
示例
main = FastMCP("main") math_server = FastMCP("math") @math_server.tool() def add(a: int, b: int) -> int: return a + b main.import_server(math_server)调用时
{ "tool": "add", "arguments": { "a": 1, "b": 2 } }适合场景
单体 MCP，但代码想模块化
给 LLM 提供“扁平、简单”的工具集合
内部复用 server
👉最像 Python 的from math_server import *
三、as_proxy——「纯代理 / MCP 网关」
概念
当前 FastMCP不自己提供工具
所有 MCP 请求转发到远程 MCP Server
本身像一个“中间人”
特点
✅ 不改后端 server
✅ 可做统一入口 / 网关
❌ 本地不能直接加 tool（通常）
示例
proxy = FastMCP.as_proxy( name="proxy", target="http://localhost:3333/mcp" )行为
LLM ⇄ proxy ⇄ real MCP server适合场景
MCP Server 在远程 / Docker / 另一台机器
想加一层：
认证
日志
访问控制
多 MCP Server 的统一入口
👉最像 Nginx / API Gateway
🔥 核心对比总结（重点）
| 维度 | mount | import_server | as_proxy |
|---|---|---|---|
| 是否保留命名空间 | ✅ | ❌ | 取决于后端 |
| tool 是否复制到本地 | ❌ | ✅ | ❌ |
| 是否远程 | ❌ | ❌ | ✅ |
| 对 LLM 友好度 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 典型用途 | 子系统 | 模块复用 | 网关 / 转发 |
怎么选？（实战建议）
🔹写一个“干净、好用”的 MCP 给 LLM
→ 用import_server🔹多个功能域，避免 tool 冲突
→ 用mount🔹已经有 MCP 服务，只想中转/暴露
→ 用as_proxy
如果你愿意，我也可以：
给你画一张结构对比图
或结合你实际用 MCP 的场景（比如 agent / tool chain）帮你选方案
四、这3种方式，对mcp server有什么要求，是否都支持http协议的mcp？
一句话结论（先记住这个）
只有
as_proxy是“真正面向 HTTP MCP Server 的”mount和import_server要求的是“Python 内存里的 FastMCP 对象”，不是一个 URL。
分别说清楚 👇
4.1mount对 MCP Server 的要求
✅ 要求
必须是本地 Python 里的 MCP Server 实例
通常是
FastMCP对象
在同一个进程 / 同一个 Python 解释器里
❌ 不支持
❌ HTTP MCP Server
❌ 远程 MCP
❌ 只有 URL 的 server
原因（关键点）
mount并不是“转发协议请求”，而是：
直接调用子 server 的内部对象
复用它的 tool registry、handler、resource
👉 本质是进程内组合，不是协议级组合
错误示例（不行）
main.mount("remote", "http://localhost:3333/mcp") # ❌4.2import_server对 MCP Server 的要求
✅ 要求
和
mount一样必须是：
本地 Python MCP Server 对象
已经定义好 tools / resources
❌ 不支持
❌ HTTP MCP Server
❌ 远程 MCP
❌ 非 Python 实例
原因
import_server做的是：
遍历另一个 server 的
tools
resources
prompts
复制注册到当前 server
👉 这是编译期 / 启动期的对象操作
类比
# import_server ≈ for tool in other_server.tools: self.register(tool)所以
没有“对象”，就没法 import
4.3as_proxy对 MCP Server 的要求（唯一支持 HTTP）
✅ 要求
目标 MCP Server 必须支持 MCP over HTTP
遵循 MCP 协议（tools/list、tools/call 等）
✅ 支持
✅ 本地 HTTP MCP
✅ 远程 HTTP MCP
✅ Docker / Kubernetes / 云端 MCP
✅ 非 Python 实现的 MCP（如 Node、Rust）
示例
proxy = FastMCP.as_proxy( name="proxy", target="http://localhost:3333/mcp" )原理
as_proxy做的是：
收到 MCP 请求
原样转发（或轻量改写）
把返回结果再传回去
👉 完全是协议层代理
🔥 一张表彻底说清楚
| 方式 | 是否要求本地 Python MCP 对象 | 是否支持 HTTP MCP | 是否支持远程 |
|---|---|---|---|
mount | ✅ 必须 | ❌ 不支持 | ❌ |
import_server | ✅ 必须 | ❌ 不支持 | ❌ |
as_proxy | ❌ 不需要 | ✅ 支持 | ✅ |
常见误区（非常重要）
❌ 误区 1
“我能不能把一个 HTTP MCP mount 进来？”
不能。mount≠ proxy，它不是走 HTTP。
❌ 误区 2
“import_server 能不能 import 一个远程 MCP？”
不能。import_server不是动态拉工具，而是静态复制对象。
✅ 正确组合方式（实战）
如果你既有远程 MCP，又想 mount / import：
远程 MCP (HTTP) ↓ as_proxy（本地） ↓ mount / import也就是：
remote = FastMCP.as_proxy( name="remote", target="http://xxx/mcp" ) main.mount("remote", remote) # ✅选型建议（直接给答案）
只要是 HTTP MCP / 远程 MCP
→先 as_proxy只在本地组合 Python MCP
→mount/import_server
