MCP Composer

聚合内网 MCP，隔离环境，访问受控。

作为 MCP 网关，把同一环境的 Redis、Kafka、MySQL、系统日志等 MCP 收成一套入口，按环境隔离后交给 Cursor 等 Agent。访问控制和身份鉴权在网关执行，而不是把权限交给模型。

前往控制中心查看文档

AI + MCP改变了这个时代的运维方式，但我们依旧会遇到一些问题

AI的行为无法监测和约束

AI在数秒内可以进行成百上千次扫描数据库，执行SQL / Shell 脚本，读取服务器敏感信息，我们既不能知道AI到底在我们的服务器上做了什么，也不能去拒绝AI的一些操作

MCP很强大，但出网困难

基于MCP，我们可以限制AI的行为，但多数生产环境的基础设施如数据库，redis等因为安全考虑只提供 exec 能力，即便你有公网域名和IP也很难安全把MCP接入到你本地的 AI Coding工具，只能SSH上去，但若给了AI SSH的能力，又等于权限全开，想要配置身份非常妥当，背后的运维理解成本极高

生产级别的MCP管理地狱

成熟的项目在TEST, PROD都会有完整的多个基础服务设施，一套测试环境可能有MYSQL, REDIS, 多个Docker服务， Kafka等N个服务一并部署，每个服务都有自己的MCP和配置，需要把每个MCP都开启鉴权，然后把这一套MCP配置给团队内的所有人，几套环境就是几十个MCP配置

多环境MCP冲突

测试环境Mysql MCP, 生产环境Mysql MCP, AI如何在弱提示的情况下知道应该调用哪个环境的MCP呢？即便有 server key的存在，但是经测试，在多数情况下，AI依旧会错调MCP

身份鉴权成难题

MCP一旦开放出去，任何拥有鉴权的Coding Agent都可以访问，什么同事在什么时候利用什么Agent 对服务器上的东西做了什么处理，我们无法得知，也没办法给不同的同事配置不同的访问权限，这对生产环境挑战非常大，当生产异常发生时，如果只有一个可读AI 去访问生产的数据，是不是可以快速定位问题并解决呢，如果用一个超高权限的AI去黑盒操作生产环境的数据，谁又敢保证这个AI 不会在1 分钟数百次的调用里出现一条意料之外的操作呢，我们甚至都看不到他做了什么，更别谈约束

MCP Composer 领先行业，带来聚合解决方案

MCP 服务的打通只需要一条支持 SSE 或者 STREAM JSON 流的传输层隧道，而相比简单传输， 更关注安全。

提供生产环境 / 敏感内网环境专用 MCP 安全策略，对 AI 的无规则调用进行有规则的控制。你可以屏蔽如删除库表、读取核心环境配置密钥等安全策略，当 AI 的此类调用进入网关时则会被自动拦截。右侧即是策略落地的样子：查询和更新可以放行，没有权限的 Tool 调用则在网关被拦截。

另一方面， 提供对 MCP 服务调用的 RBAC，你可以控制谁可以调用生产环境的 MCP 服务，能调用到什么程度，是读还是写？权限甚至可以控制到某一条具体的 SQL。

在 MCP Composer 方面的优势

多协议适配，不止SSE

无论是SSE, STREAM JSON,亦或者Exec, 都提供第一梯队支持，且支持如Mysql, Shell, Docker， RabbitMQ等多种MCP服务，适配协议广，适配服务多，且可以完全自定义对接内网MCP服务

没有上手门槛，复杂度封装到网关底层

没有复杂的 yaml配置，也没有任何心智上的负担，只需要在可视化的平台上创建一条记录，填几个字段就可以完成一套生产级别的MCP 管理中心

支持环境隔离

基于 独有的MCP Composer可以做到将一个环境内的所有MCP打包给Cursor这类AI Coding Agent，让AI不再混乱，环境隔离

始终关注MCP访问安全

除了在业务上 提供例如AI Agent 身份识别， MCP访问控制外，在云网关处，我们始终对MCP访问构建防护网络，实时扫描恶意投毒流量，以及屏蔽恶意访问来源

MCP AI领域领先

对 AI 提供第一梯队支持，自研 MCP Composer 引擎提供对内网 MCP 服务的聚合解决方案，行业领先。多个内网 MCP Tool，一条 Composer 隧道，意味着你可以将内网 MCP 服务根据不同环境、不同机器交给 AI 批量管理和维护。同时 积极适配主流 AI Agent，提供更安全稳定的 AI 解决方案。

更强大的可观测性

提供了一套完善的云端点观测机制，让你可以随时知道自身云端点的所有访问情况及 AI 调用情况。了解内网服务全链路观测

准备把现有服务接进来？

控制台已经具备云端点、网关与策略配置能力。把本地、VPC 与边缘入口接上同一条可控链路，马上开始构建。

进入控制台