Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nacos-config-mcp show me the current contents of the config dataId 'app.yml' in the default namespace"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
一个只读的 Model Context Protocol (MCP) 服务器，用于读取 Nacos 配置中心里的配置，同时兼容 Nacos 1.x / 2.x / 3.x。
它把 Nacos 的命名空间、配置检索、配置详情与历史版本能力，通过 6 个只读工具暴露给支持 MCP 的 AI 客户端（Claude Desktop、Cursor、Trae 等），让模型能够安全地查阅你的配置，而永远无法修改它们。
只读：仅使用 GET 请求（POST 仅用于登录换取 token），不提供任何发布、更新、删除配置的能力。
多版本兼容：自动探测 Nacos 大版本，并为每个操作准备有序的端点回退链；探测失败时也能通过回退链自愈。
双传输：默认 stdio，也可切换为 Streamable HTTP（无状态、可选 Bearer Token 鉴权）。
多种鉴权：匿名、Nacos 用户名/密码（1.x/2.x 的 /v1/auth/login、3.x 的 /v3/auth/user/login）、预置 access token、以及 server identity 头。
TypeScript + Node：基于官方 @modelcontextprotocol/sdk，Node.js ≥ 18.17，零运行时框架依赖。
日志走 stderr：stdout 完全留给 stdio 的 JSON-RPC 通信。
Related MCP server: jewei-mcp-nacos
能力 | Nacos 1.x | Nacos 2.x | Nacos 3.x |
登录 |
| 同 1.x |
|
命名空间列表 |
|
|
|
获取配置 |
|
|
|
搜索/列出配置 |
|
|
|
历史列表 |
|
|
|
版本探测 |
| 同 1.x |
|
默认命名空间 |
|
|
|
说明：v3 的 Console API 默认监听独立端口（通常
8080）且不带/nacos前缀，可通过NACOS_CONSOLE_URL/NACOS_CONSOLE_CONTEXT_PATH单独指定。默认命名空间在内部统一归一化为空字符串，""与"public"均会被接受。
npm install
npm run build构建产物位于 dist/，可通过 npx nacos-config-mcp 或 node dist/index.js 启动。
所有配置均可通过命令行参数或环境变量提供（命令行优先）。
命令行 | 环境变量 | 说明 | 默认值 |
|
| Nacos 服务地址，如 | 必填 |
|
| Server 端上下文路径 |
|
|
| Nacos 3.x Console 地址，如 | 与 |
|
| Console 上下文路径 | 空 |
|
| 强制指定大版本： |
|
|
| 工具未指定命名空间时使用的默认命名空间 | 空（public） |
|
| HTTP 超时（毫秒） |
|
|
| 跳过 TLS 证书校验 |
|
|
|
| 有凭据时 |
|
| Nacos 用户名 | — |
|
| Nacos 密码 | — |
|
| 预置 access token | — |
— |
| Server identity 头名称 | — |
— |
| Server identity 头取值 | — |
|
|
|
|
|
| HTTP 监听地址 |
|
|
| HTTP 监听端口 |
|
|
| HTTP 端点路径 |
|
|
| HTTP 请求所需的 Bearer Token | 不校验 |
|
|
|
|
Claude Desktop / Cursor / Trae 等客户端配置示例：
{
"mcpServers": {
"nacos-config": {
"command": "npx",
"args": ["-y", "nacos-config-mcp"],
"env": {
"NACOS_BASE_URL": "http://127.0.0.1:8848",
"NACOS_USERNAME": "nacos",
"NACOS_PASSWORD": "nacos"
}
}
}
}使用本地构建产物时：
{
"mcpServers": {
"nacos-config": {
"command": "node",
"args": ["/absolute/path/to/nacos-config-mcp/dist/index.js"],
"env": {
"NACOS_BASE_URL": "http://127.0.0.1:8848"
}
}
}
}NACOS_BASE_URL=http://127.0.0.1:8848 \
MCP_TRANSPORT=http MCP_HTTP_PORT=3000 MCP_HTTP_TOKEN=secret \
node dist/index.js端点：http://127.0.0.1:3000/mcp（无状态模式，仅接受 POST）。设置 MCP_HTTP_TOKEN 后，请求需携带 Authorization: Bearer secret。
工具 | 说明 | 主要参数 |
| 报告连接信息：探测到的版本、大版本、实际使用的端点、上下文路径与鉴权方式。排查连通性/版本问题时优先调用。 | 无 |
| 列出命名空间（租户），可按命名空间 ID 过滤。 |
|
| 搜索/分页浏览配置项，支持精确/模糊匹配与分组、应用名、标签、类型过滤。返回分页摘要（不含内容）。 |
|
| 读取单个配置的完整内容与元数据。 |
|
| 列出配置的历史修订，返回可传给详情工具的修订 ID（ |
|
| 读取某个历史修订的内容与元数据。 |
|
所有工具均带有 readOnlyHint: true、destructiveHint: false 注解，单页最多返回 500 条（pageSize 上限）。
HTTP 客户端只允许 GET 与 POST 两种方法（client.ts），POST 仅用于登录换取 token。
代码中不存在任何发布、更新、删除配置的端点。
所有工具均标注为只读。
npm run dev # 以 tsx 直接运行源码
npm run build # 编译到 dist/
npm run typecheck # 类型检查（不产出文件）
npm test # 运行 vitest 单测src/
├── index.ts # CLI 入口：分发 stdio / http
├── server.ts # 组装 HttpClient/Auth/Version/Api 与 McpServer
├── config.ts # 参数与环境变量解析
├── nacos/
│ ├── client.ts # 只读 HTTP 客户端（超时、重试）
│ ├── auth.ts # 登录与 token 缓存
│ ├── version.ts # 大版本探测
│ ├── api.ts # 多版本兼容 API 层 + 解析器
│ └── types.ts # 领域类型
├── tools/ # 6 个 MCP 工具
└── util/ # 错误、日志、文本工具Read the full content and metadata of a single configuration entry identified by dataId + group + namespace. Compatible with Nacos 1.x, 2.x and 3.x; on Nacos 1.x the raw text body is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Configuration group, e.g. DEFAULT_GROUP. | |
| dataId | Yes | Configuration data ID, e.g. application.yaml. | |
| namespaceId | No | Namespace (tenant) ID. Omit to use the namespace configured for this server. The default namespace is "" on Nacos 1.x/2.x and "public" on Nacos 3.x; both are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-obvious behavior: compatibility with Nacos 1.x/2.x/3.x and the raw-text-body return on Nacos 1.x. It does not enumerate every return field, but it goes beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core read action and identity fields front-loaded, followed by version compatibility and the return-format caveat. Every sentence earns its place and there is no redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully explains that the tool returns 'full content and metadata' and clarifies the Nacos 1.x raw-body behavior. It does not enumerate metadata fields or error cases, but for a simple config-fetch tool this is reasonably complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters, including the namespace default behavior. The description adds the identity relationship ('identified by dataId + group + namespace') and single-entry scope, but it does not materially deepen the meaning of the parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Read' and names the exact resource: 'full content and metadata of a single configuration entry'. It also lists the identifying fields (dataId + group + namespace), which clearly distinguishes this from sibling search/list/history tools that operate over multiple entries or historical versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'single configuration entry' and the need for exact identifiers imply this tool is for fetching one known config rather than discovering or browsing configs. However, no sibling tool is named and no explicit when-to-use/when-not-to-use guidance is provided, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the content and metadata of one historical revision of a configuration entry. Use the revision id (nid) returned by nacos_list_config_history. Compatible with Nacos 1.x, 2.x and 3.x.
| Name | Required | Description | Default |
|---|---|---|---|
| nid | Yes | Revision id of the history entry, from nacos_list_config_history. | |
| group | No | Configuration group, e.g. DEFAULT_GROUP. | |
| dataId | Yes | Configuration data ID, e.g. application.yaml. | |
| namespaceId | No | Namespace (tenant) ID. Omit to use the namespace configured for this server. The default namespace is "" on Nacos 1.x/2.x and "public" on Nacos 3.x; both are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by clarifying that this reads a historical revision (not current config), that the nid comes from the list tool, and that namespace behavior differs across Nacos versions (default namespace is '' on 1.x/2.x and 'public' on 3.x, both accepted). This is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The core action and resource are front-loaded, the critical prerequisite (nid from the list tool) is stated immediately, and the compatibility note is a single compact sentence. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description covers the essential context: what it reads, how to obtain the required nid, and version compatibility. The namespace default behavior is already in the schema. The only minor gap is that it doesn't describe the return format or whether the content is returned raw or parsed, but for a simple read operation with strong annotations and schema coverage, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds the key semantic link that nid is the revision id from nacos_list_config_history, which is valuable. However, it doesn't add much beyond that for group, dataId, or namespaceId, since the schema already provides examples and the namespace default behavior is described in the schema. Baseline 3 is appropriate because the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a specific resource ('content and metadata of one historical revision of a configuration entry'), and explicitly distinguishes it from the sibling list tool by referencing the revision id returned by nacos_list_config_history. This makes the tool's purpose unambiguous and differentiates it from nacos_get_config and nacos_list_config_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use the revision id (nid) returned by nacos_list_config_history, which is a clear prerequisite and usage instruction. It also states compatibility with Nacos 1.x, 2.x, and 3.x, which helps the agent know when this tool is applicable. While it doesn't explicitly name alternatives, the reference to the sibling list tool and the clear 'read one historical revision' scope provides strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the revision history of a configuration entry. Each item carries the revision id (nid) that can be passed to nacos_get_config_history_detail to read that revision. Compatible with Nacos 1.x, 2.x and 3.x.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Configuration group, e.g. DEFAULT_GROUP. | |
| dataId | Yes | Configuration data ID, e.g. application.yaml. | |
| pageNo | No | 1-based page number, defaults to 1. | |
| pageSize | No | Items per page between 1 and 500, defaults to 20. | |
| namespaceId | No | Namespace (tenant) ID. Omit to use the namespace configured for this server. The default namespace is "" on Nacos 1.x/2.x and "public" on Nacos 3.x; both are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond that: the returned items are revision summaries carrying an nid usable for detail retrieval, and the tool is compatible across Nacos 1.x, 2.x, and 3.x. This is meaningful without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The primary purpose is front-loaded, the nid-to-detail relationship is stated in one clause, and version compatibility is a compact final addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with five well-documented parameters and clear annotations, the description is mostly complete. It explains the output's key field and the follow-up tool, though with no output schema it could have said slightly more about other returned fields or default ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents every parameter. The tool description adds no new parameter-level detail, which is acceptable under the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'List the revision history of a configuration entry.' It also clarifies the output's role by noting each item carries a revision id (nid), which clearly separates this from current-config tools like nacos_get_config and from search-oriented tools like nacos_search_configs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by positioning this tool as the listing step whose nid feeds into nacos_get_config_history_detail. It does not explicitly state when to avoid this tool or name alternatives such as nacos_get_config, but the workflow implication is strong and the sibling tool is referenced directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the namespaces (tenants) available on the Nacos server, optionally filtered to a single namespace ID. Works across Nacos 1.x, 2.x and 3.x.
| Name | Required | Description | Default |
|---|---|---|---|
| namespaceId | No | Namespace (tenant) ID. Omit to use the namespace configured for this server. The default namespace is "" on Nacos 1.x/2.x and "public" on Nacos 3.x; both are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds cross-version compatibility and optional filtering, but does not describe return shape, pagination, or error behavior. This is acceptable for a simple read-only list operation but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence delivers the core purpose, the optional parameter behavior, and version compatibility without any wasted words. Key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with one optional parameter, the combination of description, schema, and annotations fully supports correct selection and invocation. No critical information about when or how to call the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the namespaceId parameter already includes detail about omitting it and default namespace differences across versions. The description's mention of optional filtering reinforces the schema without adding significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('namespaces (tenants) available on the Nacos server'), and an optional filtering behavior ('optionally filtered to a single namespace ID'). It is easily distinguished from sibling tools that deal with server info or configs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it obvious when to use the tool: when namespace/tenant information is needed. It does not explicitly name alternatives or exclusions, but the resource-specific phrasing and sibling context make mis-selection unlikely. It also notes cross-version compatibility, which adds useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or page through configuration entries in a namespace. Supports exact and fuzzy matching on dataId, plus filters for group, application name, tags and content type. Returns paged summaries (without content); call nacos_get_config to read a value. Compatible with Nacos 1.x, 2.x and 3.x.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by configuration type, e.g. yaml, properties, json. | |
| group | No | Configuration group, e.g. DEFAULT_GROUP. | |
| dataId | No | Data ID pattern to match. Leave empty to list everything in the namespace. | |
| pageNo | No | 1-based page number, defaults to 1. | |
| search | No | Matching mode for dataId/group: "accurate" (exact) or "blur" (wildcard). Defaults to blur. | |
| appName | No | Filter by the owning application name. | |
| pageSize | No | Items per page between 1 and 500, defaults to 20. | |
| configTags | No | Filter by configuration tags. | |
| namespaceId | No | Namespace (tenant) ID. Omit to use the namespace configured for this server. The default namespace is "" on Nacos 1.x/2.x and "public" on Nacos 3.x; both are accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable behavioral context by stating the result is a paged summary without content, and by noting compatibility across Nacos major versions, which informs how results and namespace semantics may vary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, starting with the core purpose and then layering matching modes, return behavior, routing guidance, and compatibility. Every sentence adds distinct information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description efficiently covers what is returned (paged summaries without content), which is essential caller knowledge. Combined with the fully described 9-parameter schema and annotations, the context is complete enough for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter individually. The description adds a high-level view of filters and matching modes, but no significant new parameter-level meaning beyond what the schema provides, justifying the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches and pages through configuration entries in a namespace, with specific filters and matching modes. It also distinguishes itself from nacos_get_config by noting it returns summaries without content, making the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context for searching and paging configs, and explicitly directs agents to nacos_get_config when the actual value is needed. It does not, however, contrast itself with the history-related siblings such as nacos_list_config_history, leaving some routing ambiguity for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report how this MCP server is connected to Nacos: detected server version, major version, the API endpoints actually in use, context path and authentication mode. Use this first when troubleshooting connectivity or version compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat these. It adds context by specifying exactly what information is reported (version, endpoints, auth mode), which goes beyond annotations and helps the agent understand the tool's output nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact—two sentences with no filler. The purpose is front-loaded, followed by the specific data points reported and the usage guidance. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool without an output schema, the description fully covers what the agent needs: what the tool does, what details it reports, and when to use it. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% (empty object). Per the baseline for zero-parameter tools, a score of 4 is appropriate. The description doesn't need to explain any parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports how the server is connected to Nacos, enumerating the specific details (version, endpoints, context path, auth mode). This distinguishes it from sibling tools that operate on namespaces or configs, making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool first when troubleshooting connectivity or version compatibility, giving a clear when-to-use directive. While it doesn't name alternatives, the priority and scenario are specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0nacos_get_confignacos_get_config_history_detailnacos_list_config_historynacos_list_namespacesnacos_search_configsnacos_server_infoScored across 6 tools
Each tool targets a distinct action: server info, namespace listing, config search, config content retrieval, and history list/detail. The search tool explicitly returns summaries without content and points to get_config, so there is no functional overlap.
All tool names share a consistent nacos_ prefix and mostly follow the verb_noun pattern (list_namespaces, search_configs, get_config, list_config_history). The only deviation is nacos_server_info, which lacks a verb, but this is a minor inconsistency.
Six tools is a well-scoped set for reading Nacos configurations and their history. Each tool has a clear purpose and none feel redundant.
The read-side coverage is solid: namespaces, search, content retrieval, and full history review are all present. However, there are no create, update, delete, publish, or remove operations, leaving the configuration lifecycle incomplete.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Discover MCP servers, A2A agents, and shared agent knowledge through a read-only MCP gateway.
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
