MCP 是什么
MCP(Model Context Protocol)是一种让 AI 应用连接外部上下文和工具的协议。可以把它理解为 AI 世界的“适配层”:Host 是承载 Agent 的应用,Client 负责连接,Server 暴露 Tools、Resources 和 Prompts。
1 | Host(Agent / IDE) |
MCP 与普通 API 的区别
普通 API 面向业务程序员,MCP 更强调让模型理解能力边界、参数描述和返回结果。它不是替代权限系统,也不是把数据库裸奔给模型;每一个 Tool 仍然应该做输入校验、权限校验、审计和最小化返回。
一个前端项目的 MCP Server
可以为项目提供“读取页面清单”和“检查路由”的工具:
1 | server.tool("find_page", "按菜单 Code 查找页面", { |
Agent 因此能够先读取真实注册信息,再提出修改方案,而不是凭经验猜目录结构。
工具、资源和提示词
- Tools:有副作用的动作,例如运行测试、生成页面、查询接口。
- Resources:只读上下文,例如设计规范、路由表、接口文档。
- Prompts:经过验证的任务模板,例如“按项目规范新增一个菜单页面”。
一个成熟系统通常先开放 Resources,再开放只读 Tools,最后对写操作增加人工确认。
安全边界
MCP Server 不应直接暴露生产 Token、用户隐私和任意 Shell。工具参数要有 Schema,来源要可识别,危险动作要二次确认,返回结果要脱敏。对前端团队而言,代码仓库、依赖清单和接口契约都可以作为上下文,但密钥永远不应成为上下文。
如何在前端项目中引入
不需要一开始就把整个公司系统接入 MCP。可以从一个只读 Server 开始,放在项目或团队工具目录中:
1 | tools/mcp/ |
第一阶段只提供读取页面、菜单、组件文档和检查结果的能力;第二阶段再增加生成测试、运行局部检查等低风险动作;修改文件、提交代码和发布操作应继续由开发者明确确认。
1 | const context = await mcp.readResource("project://routes"); |
MCP 在日常开发中的使用方式
一个可落地的任务可以这样执行:先让 Agent 查询现有菜单和页面,再读取设计规范;Agent 输出方案后,由开发者确认;实现时调用本地检查工具;最后把检查结果写入任务报告。这样 Agent 的回答来自项目当前状态,而不是来自过期记忆。
MCP Server 的工具描述也要像公共 API 一样维护。名称要表达动作,参数要有类型,返回值要稳定,并提供失败信息。工具调用日志只记录必要的任务信息,不把源代码、用户数据和凭证无差别写入日志。
小结
MCP 解决的是“Agent 如何连接真实世界”,重点是协议化、可发现和可治理。它让 Agent 从通用问答进入具体项目,但最终质量仍取决于上下文质量和权限设计。
