MCP 到底解决什么：Host、Client、Server 与 Tools 一次讲清

如果每个 Agent 都要为数据库、文件、GitHub 和企业系统各写一套私有连接方式，集成成本会不断重复。MCP（Model Context Protocol）解决的是“AI 应用如何用统一方式发现和调用外部能力”。

一、先看清 MCP 的位置

用户
  ↓
AI 应用 / Host
  ↓ 管理连接与授权
MCP Client
  ↓ 协议请求
MCP Server
  ↓
数据库、文件、API、内部业务系统

Host：用户实际使用的 AI 应用，负责权限、连接和交互。
Client：Host 内负责与某个 MCP Server 通信的协议组件。
Server：把外部数据或动作封装成标准能力。

二、MCP Server 可以提供什么

Tools：模型可以调用的动作，例如查询订单、创建工单、执行计算。
Resources：可读取的上下文和数据，例如文档、配置或数据库记录。
Prompts：可复用的提示模板和工作流入口。

MCP 并不替模型思考，也不自动保证工具安全。它统一的是连接和能力描述；是否调用、是否批准、能访问什么，仍由 Host、用户和服务端权限共同决定。

三、五分钟写一个 Python MCP Server

mkdir knowhub-mcp
cd knowhub-mcp
python -m venv .venv
source .venv/bin/activate
pip install "mcp[cli]"

创建 server.py：

from mcp.server import MCPServer

mcp = MCPServer("KnowHub Demo")


@mcp.tool()
def check_port(host: str, port: int) -> dict:
    """返回需要检查的主机和端口；示例不执行真实网络连接。"""
    if not 1 <= port <= 65535:
        raise ValueError("端口必须在 1 到 65535 之间")
    return {"host": host, "port": port, "next": "run approved connectivity check"}


@mcp.resource("guide://docker/first-check")
def first_check() -> str:
    """容器无法访问时的第一步。"""
    return "先检查 docker compose ps 和最近 100 行日志。"

用官方调试工具启动并检查：

mcp dev server.py

Inspector 会根据函数类型提示生成参数表单。先验证工具列表、正常输入、非法端口和错误返回，再接入真实 Host。

四、STDIO 与远程 HTTP 怎么选

STDIO：适合本机工具和开发环境，由 Host 启动子进程；凭据通常从受控环境变量读取。
远程 HTTP：适合团队或 SaaS 服务，需要 HTTPS、身份认证、授权范围、限流和审计。

不要为了“看起来云原生”把只供个人使用的本地工具暴露到公网。部署方式应该由使用范围和信任边界决定。

五、MCP 最大风险不是协议，而是权限

只给读取需求提供只读工具，不要顺手暴露删除和修改。
每个工具都要验证参数、资源归属和调用者身份。
Token 不写入 URL、日志、提示词或工具返回。
高风险写操作显示目标和影响范围，由用户明确批准。
远程服务使用 HTTPS 和规范授权，遵循最小权限。
不要安装来源不明的 MCP Server；它本质上可能执行代码并访问数据。

六、设计好工具的四个标准

单一职责：get_order 与 refund_order 分开。
参数明确：使用结构化字段和枚举，避免让模型拼一段任意 Shell。
结果可验证：返回状态、资源 ID、时间和下一步，而不是只说“成功”。
错误可处理：区分无权限、参数错误、资源不存在和服务暂不可用。

版本提醒

MCP 仍在快速演进。2026-07-28 规范强化了无状态协议核心、扩展机制与授权能力。生产项目应固定 SDK 版本、记录协议兼容范围，并通过官方 SDK 与 Inspector 测试，不建议手写底层协议。

官方资料

下一篇：Agent Skills 实战：把经验写成 AI 可复用的工作流