MCP 是 Model Context Protocol，可以理解成一套让 AI 应用标准化连接外部数据、工具和服务的开放协议。它解决的不是“模型怎么训练”或“Prompt 怎么写”的问题，而是解决大模型应用如何安全、稳定、可扩展地获取上下文和调用外部能力的问题。官方规范也把它定义为连接 LLM 应用与外部数据源、工具的开放协议：Model Context Protocol Specification。

从工程角度看，MCP 类似 AI 应用领域的“统一适配层”。没有 MCP 之前，一个 AI IDE 要接 GitHub、数据库、文件系统、日志平台、设计稿平台，往往需要为每个系统单独写一套插件或接口适配。MCP 把这件事抽象成统一的 Client-Server 模型：AI 应用作为 Host，内部创建 MCP Client；外部能力由 MCP Server 暴露，比如文件读取、数据库查询、代码仓库检索、API 调用等。

MCP Server 通常会暴露三类能力：tools、resources 和 prompts。tools 更偏动作调用，比如执行查询、创建任务、触发部署；resources 更偏上下文读取，比如读取文档、代码文件、配置、日志；prompts 则是服务端预置的一些结构化提示模板。客户端会通过协议发现这些能力，再在用户授权或应用策略允许的情况下调用。

协议层面，MCP 基于 JSON-RPC 通信，并包含初始化、能力协商、正常通信、关闭等生命周期。传输方式可以是本地的 stdio，也可以是远程 HTTP。这个设计让 MCP 既能用于本地开发工具，比如 Claude Desktop、AI IDE，也能用于企业内部平台，把知识库、工单系统、监控系统、代码仓库等接入 AI 助手。

对于前端团队来说，MCP 的价值会非常直接。比如可以做一个连接组件库文档、设计规范、业务接口文档、Git 仓库和构建日志的 MCP Server，让 AI 助手不只是泛泛回答问题，而是能基于当前项目的真实上下文分析代码、定位问题、生成更符合团队规范的实现方案。

但 MCP 也不是万能的。它只是协议和连接方式，不负责保证外部工具调用一定安全，也不自动解决权限控制、数据泄露、Prompt Injection、操作审计等问题。真正落地时，MCP Server 需要做权限边界、参数校验、敏感数据过滤、用户确认和日志追踪，否则“让模型能调用工具”会变成新的安全风险入口。