企业接入 MCP，有三条路：代理、托管，还是把 API 转成 Tool？

企业准备把 Agent 接入业务系统时，常见的第一个问题是：MCP到底怎么接？

有的团队已经有可用的 MCP 服务，只想快速接入；有的团队希望把服务统一放到平台里管理；还有大量存量系统，手上只有 REST 或 SOAP API。

这三种情况，对应三种常见的 MCP 接入模式。

一、已有 MCP 服务，可以先用代理 MCP

代理 MCP（Proxy MCP）适合企业已经拥有成熟 MCP 服务，或者外部合作方已经提供 MCP 服务的情况。

平台不需要重新实现服务，只需配置服务地址、认证信息和相关调用策略，让 Agent通过统一入口访问已有能力。

这种方式接入速度较快，改造量也相对小。它适合验证场景，或者企业已经有明确的 MCP 服务供应体系。

不过，代理接入不等于完全不用治理。服务的身份认证、调用权限、版本变化、可用性和日志记录，仍然需要纳入企业管理范围。

二、需要统一管理，可以选择托管 MCP

托管 MCP（Hosted MCP）是把 MCP 服务实例运行在平台上，由平台负责服务创建、注册、权限配置和运行管理。

对于需要长期运营的企业场景，托管方式更容易统一管理。服务由谁维护、哪些 Agent可以调用、版本如何更新、异常如何发现，都可以放在同一套管理体系里处理。

这类方式更适合企业内部工具、关键业务服务和需要审计的生产场景。平台还可以结合安全网关做流量控制、协议校验和防护策略，减少工具接入散落在不同应用里的情况。

三、只有 API，可以用 API-to-MCP

很多企业并没有现成的 MCP 服务，但已经积累了大量 REST 或 SOAP API。为了让 Agent使用这些存量能力，可以采用 API-to-MCP，将 API 定义转换成 MCP Tool。

这种方式的价值在于减少重复改造。企业不必先把所有后端系统重写成新的服务，再开始做 Agent；可以先整理已有 API 的业务语义、参数规则、返回结构和权限要求，再生成可调用的工具。

但“能转换”不等于“适合直接给 Agent调用”。有些 API 面向系统内部使用，参数复杂、返回字段过多，或者缺少业务校验。转换之后仍需要补充工具描述、输入校验、错误处理和人工确认策略。

四、三种模式怎么选

可以先问三个问题。

第一，手上是否已经有可用的 MCP 服务？有的话，代理 MCP通常是更快的起点。

第二，这项能力是否要长期服务多个 Agent，是否需要统一审计和版本管理？如果需要，托管 MCP更合适。

第三，存量系统是否主要通过 REST 或 SOAP API提供能力？如果是，API-to-MCP可以减少前期改造工作。

实际项目也可能混用三种模式。企业可以先用 API-to-MCP验证业务场景，再把稳定、高频的工具纳入托管；外部成熟服务则通过代理方式接入。

五、接入模式之后，还有一层运营工作

MCP接入完成后，仍要维护服务目录、工具说明、权限关系、版本变化和调用记录。工具被 Agent调用的次数增加后，还要观察哪些能力常用，哪些经常失败，哪些动作需要重新设计。

得帆的 Dolphin Integration 将系统集成、自动化、MCP中台和 AI 网关放在连接层中管理，得小帆负责将这些能力编排进员工可用的智能体任务。

写在最后

代理 MCP解决快速接入，托管 MCP解决统一管理，API-to-MCP解决存量 API 的标准化使用。三种模式没有固定的优先级，关键是看企业已有的系统基础、治理要求和业务目标。

先选对接入方式，再考虑工具如何长期运行，MCP才不会停在一次性的技术演示里。