在 MCP 出现之前，Agent 接入工具主要靠“定制化集成”。

通常做法是：在 Agent 外面写一层执行器或编排层，把可用工具包装成函数、插件、API 调用或脚本。开发者需要手动定义工具名称、参数结构、描述信息和调用逻辑，然后把这些信息放进 Prompt、函数调用 schema，或框架提供的 Tool 抽象里。模型决定要调用哪个工具后，Agent Runtime 解析模型输出，执行对应代码，再把执行结果追加回上下文，让模型继续推理。

例如，一个前端研发场景里的 Agent 想接入 GitHub、Jira、Figma、数据库、浏览器自动化工具，通常会这样做：

复制
1const tools = {
2  searchIssue: async (params) => jiraClient.search(params),
3  getFigmaFile: async (params) => figmaClient.getFile(params.fileKey),
4  runCommand: async (params) => exec(params.command),
5};

再把这些工具的说明提供给模型，让模型输出类似：

复制
1{
2  "tool": "searchIssue",
3  "params": {
4    "keyword": "login bug"
5  }
6}

Agent 框架拿到这个结构后，找到对应函数执行，并把结果返回给模型。

这种方式在早期已经能工作，像 OpenAI Function Calling、LangChain Tools、LlamaIndex Tools、IDE 插件、企业内部 Bot 平台，本质上都是类似思路：模型负责决策，宿主程序负责工具注册、权限控制、执行和结果回填。

但问题也很明显。每个平台都有自己的工具定义方式、通信方式和权限模型。一个 GitHub 工具如果接入了某个 Agent 框架，换到另一个 IDE、另一个模型供应商或另一个 Agent Runtime，往往要重新适配。工具发现、参数描述、错误处理、鉴权、日志、资源访问、上下文注入都没有统一规范，最终导致集成成本高、复用性差，也不利于企业级治理。

MCP 解决的正是这类问题。它把工具、资源、提示词等能力抽象成统一协议，让 Agent Client 可以通过标准方式连接 MCP Server。这样工具提供方不需要为每个 Agent 单独写适配，Agent 也不需要为每种工具维护一套私有接入逻辑。