用 Cognipeer Console 把 API 变成 MCP 服务器：面向 AI Agent 的工具暴露实战

AI Agent 真正能干活的前提，是它能够发现并调用带有清晰契约的工具。Cognipeer Console 的 MCP Servers 功能，正是把企业现有的 API 转化为符合 Model Context Protocol（模型上下文协议，MCP）规范的服务器，让任意兼容 MCP 的 Agent 都能即插即用地调用。本文基于官方演示，拆解从 OpenAPI 创建服务器、检视工具、发布 Hub 目录到运行监控的完整链路。

从 OpenAPI 规范创建一个 MCP 服务器

在 Console 中打开 MCP Servers 列表，每一个服务器都代表一组可通过 MCP 对外暴露的 API 接口。演示环境里已经预置了 OMS MCP 和 DeepWiki 两个示例，方便直接参考结构。

新建服务器时，需要填写名称、描述和服务器密钥（server key）。关键一步在 Tool Source（工具来源）中选择 OpenAPI，随后填入目标 API 的上游 Base URL，再提供 OpenAPI 规范本身——可以直接粘贴 JSON/YAML 内容、上传文件，或从 URL 加载。演示中展示的是粘贴 OMS 的 OpenAPI 规范。

创建前先过一遍 Preflight（预检）环节，确认规范解析无误后点击 Create Server。这种基于 OpenAPI 的生成方式，意味着企业不必手工为每个接口编写 MCP 工具定义，而是复用既有的 API 文档，大幅降低了接入成本。

Model Context Protocol（MCP） 是 Anthropic 于2024年底提出的开放标准，旨在为大语言模型与外部工具/数据源之间定义一套统一的通信协议。类比于 USB 接口统一了外设连接方式，MCP 试图统一 AI Agent 调用工具的方式——无论底层是数据库查询、REST API 还是本地文件系统，Agent 只需遵循同一套协议就能发现并调用它们。协议的核心概念包括三类原语：Tools（工具，供 Agent 主动调用的函数）、Resources（资源，Agent 可读取的数据）和 Prompts（提示模板）。目前 Claude、Cursor、Zed 等主流 AI 产品已原生支持 MCP，第三方生态也在快速扩展。理解这一背景有助于把握为何 OpenAPI → MCP 的自动映射具有实际价值：企业存量的数千个 REST 接口，可借此批量进入 Agent 可调用的工具生态，而不必为每个 Agent 框架单独适配。

检视生成的工具与暴露详情

服务器创建完成后，进入详情页的 Tools（工具）标签，就能看到由 OpenAPI 规范自动映射出的工具集。以 OMS MCP 为例，它暴露了 Lookup Order（查询订单）、Open Carrier Trace（查看承运商轨迹）、Check Return and Eligibility（检查退货资格）等工具。

这种显式的工具清单，正是 MCP 协议价值所在——Agent 不需要猜测 API 能做什么，而是直接读到一份明确的能力契约。回到 Overview 页可以确认该服务器的 OpenAPI 工具来源，而 Exposure（暴露）区块则用于审视服务器对外的开放方式，配合 Total Requests（总请求数）和 Top Tools（热门工具）给出简洁的活跃度视图。

MCP Hubs：面向团队的服务发现目录

MCP Hubs 是 MCP Servers 中的企业级能力，用来发布经过筛选的 MCP 服务器目录（curated catalog）。它的核心场景是：平台团队把希望客户端一同发现的多个服务器组织到一起，形成一个统一的发现入口。

换句话说，Hub 本质上扮演了一个「发现 API」的角色。当企业内部的 MCP 服务器越来越多时，散落的单个服务器会给调用方带来治理难题，而 Hub 让平台团队能够主动策展、按需暴露，兼顾了可发现性与访问控制。这对大中型组织的 Agent 工具治理尤为重要。

「服务发现」是微服务架构中的经典问题：当服务实例数量增长后，调用方需要一个集中的注册中心来查询「谁在哪里、能做什么」，而不是把地址硬编码在代码里。Consul、Eureka、Kubernetes Service 都是这一思路的体现。MCP Hub 在 Agent 工具层面解决的是同构问题：随着企业内部 MCP 服务器从数个增长到数十甚至数百个，分散注册会导致 Agent 配置碎片化、权限难以统一审计。Hub 充当「工具注册中心」，平台团队在此进行策展（curate）——决定哪些服务器对外可见、以何种权限暴露——Agent 只需订阅 Hub 端点即可获取最新的可用工具列表。这与 API Gateway 在 REST 生态中的治理职责高度类似，只是作用层次从网络路由上移到了语义工具描述层。

监控与 Agent 侧的工具接入

服务器投入使用后，Monitor（监控）面板集中呈现服务器数量、请求量、错误信号、延迟以及降级（degraded）状态。需要特别说明的是，演示中出现的错误与降级数值是通过故意传入无效订单号制造的示意信号，并非真实的生产可靠性指标——这是理解面板数据时容易被误读的一点。

在 Agent 侧，打开 Console Agent 的 Build 标签，在 Tools 区块即可配置 Agent 可用的工具。有意思的是，这个界面本身并不提供专门的「MCP 服务器选择器」。同一个 MCP 服务器还可以通过 Agent SDK 的 MCP 插件、以及 Pulse 设置连接到 MCP 服务器。

多条接入路径意味着无论你是在可视化 Console 里搭建 Agent，还是用代码通过 SDK 编排，都能复用同一套 MCP 服务器定义，避免重复建设。

完整工作流小结

整条链路可以概括为五步：从 MCP Servers 列表出发；基于 OpenAPI 规范创建服务器并完成预检；检视生成的工具、审查暴露详情；在企业版中发布策展过的 MCP Hub 目录作为发现 API；最后用 Monitor 观察运行信号，并为 Agent 配置所需工具。

对于已经积累了大量 REST API 的团队来说，这套流程的最大意义在于：几乎零改造地把现有接口标准化为 Agent 可消费的工具，再借助 Hub 和 Monitor 完成组织与运维，让 AI Agent 的工具供给从「临时拼接」走向「平台化治理」。