Click on "Install 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., "@apollo-mcp-server show config for namespace 'application' in DEV cluster"
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.
Apollo 配置中心的 MCP (Model Context Protocol) 服务，使大语言模型能够通过配置的 Apollo 地址和 Token 对 Apollo 进行查询和操作。支持 Cursor、Trae、Claude Desktop 等 MCP 客户端。
基于 Apollo 开放平台接口文档 实现以下能力：
应用与集群：list_apps、get_app_env_clusters、get_cluster、create_cluster
命名空间：list_namespaces、get_namespace、create_namespace、get_namespace_lock
配置项：list_items、get_item、create_item、update_item、delete_item
发布与回滚：get_latest_release、publish_release、rollback_release
应用创建：create_app
Related MCP server: mcp-apollo-config
Apollo Portal 已部署并可访问
在 Portal 的 http://{portal_address}/open/add-consumer.html 创建第三方应用并获取 Token
在 http://{portal_address}/open/manage.html 为 Token 绑定可操作的 Namespace
具体可参考官方指引: https://www.apolloconfig.com/#/zh/portal/apollo-open-api-platform
pip install apollo-mcp-server或使用 uvx 无需安装即可运行：
uvx apollo-mcp-server --url http://your-apollo:8070 --token your_tokenpip install -e .
# 或
uv pip install -e .apollo-mcp-server --url http://your-apollo-portal:8070 --token your_open_api_token
--url为 Apollo Portal 根地址（不含/openapi/v1/后缀），如http://localhost:8070。
或
python -m mcp_server_apollo --url http://your-apollo-portal:8070 --token your_open_api_token在 ~/.cursor/mcp.json（Cursor）、Trae 或 claude_desktop_config.json（Claude）中添加：
{
"mcpServers": {
"apollo": {
"command": "uvx",
"args": [
"apollo-mcp-server",
"--url",
"http://your-apollo-portal:8070",
"--token",
"your_open_api_token"
]
}
}
}也可通过环境变量配置（需 apollo-mcp-server >= 1.0.0）：
{
"mcpServers": {
"apollo": {
"command": "uvx",
"args": ["apollo-mcp-server"],
"env": {
"APOLLO_URL": "http://your-apollo-portal:8070",
"APOLLO_TOKEN": "your_open_api_token"
}
}
}
}# 安装依赖
pip install -e .
# 本地运行（无需安装，从项目目录）
PYTHONPATH=src python -m mcp_server_apollo --url http://localhost:8070 --token your_token
# 或安装后直接运行
apollo-mcp-server --url http://localhost:8070 --token your_tokenMIT License
创建 App 并授权。需在创建第三方应用时勾选允许创建 app。
| Name | Required | Description | Default |
|---|---|---|---|
| assignAppRoleToSelf | Yes | 是否授予自己管理权限 | |
| admins | No | 授予管理权限的用户列表，可选 | |
| app | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions authorization and a prerequisite. It fails to disclose behavioral traits such as idempotency, permission requirements, or side effects, which are critical for a creation tool.
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 brief—one sentence plus a note. It is front-loaded but could be more structured without adding significant length.
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 the lack of output schema and nested object parameters, the description is insufficient. It does not explain return values, the app object structure, or the full authorization flow.
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 67% (two of three top-level params have descriptions). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 it creates and authorizes an app ('创建 App 并授权'), which differentiates it from sibling tools like create_cluster or create_item. However, it could be more explicit about the type of app and context (third-party).
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 includes a prerequisite ('需在创建第三方应用时勾选允许创建 app'), but does not specify when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建集群。需要授予第三方 APP 对目标 APP 的管理权限。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| name | Yes | 集群名 | |
| dataChangeCreatedBy | Yes | 创建人，域账号 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses a permission requirement but does not explain error handling, side effects, or success conditions for a mutation tool.
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?
Extremely concise with two sentences. Front-loaded with the primary action. No unnecessary words, but some important details are missing.
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 tool with no annotations, no output schema, and 4 required parameters, the description is too brief. It lacks context on cluster purpose, parameter roles, and expected outcomes.
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 50%. The description adds no extra meaning to parameters; it does not explain appId or env, and only minimally describes name and dataChangeCreatedBy. The main description does not complement the schema gaps.
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 creates a cluster ('创建集群'), but does not explicitly differentiate from sibling tools like create_app or create_namespace. However, the verb+resource is specific enough.
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 mentions a prerequisite (granting third-party APP management permissions), but provides no guidance on when to use this tool vs alternatives, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
新增配置项。key 长度不超过 128 字符，value 不超过 20000 字符。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes | ||
| key | Yes | ||
| value | Yes | ||
| dataChangeCreatedBy | Yes | ||
| comment | No | 可选 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses length limits. It does not mention idempotency, overwrite behavior, auth requirements, or side effects like notifications. For a mutation tool, critical behaviors are missing.
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 with two sentences, no filler. However, it could be better structured by grouping parameter explanations.
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 8 parameters, no output schema, and no annotations, the description is insufficient. It lacks return value information, error handling, and parameter interplay, leaving the agent underinformed for correct invocation.
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 only 13%, yet the description only clarifies two parameters (key, value). The remaining 6 parameters (appId, env, clusterName, namespaceName, dataChangeCreatedBy, comment) have no description or added semantics, leaving the agent to guess their role.
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 this tool creates a configuration item ('新增配置项'), and adds specific constraints for key and value lengths, distinguishing it from siblings like create_app or delete_item.
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?
No guidance on when to use this tool versus alternatives like update_item or delete_item. The description does not mention prerequisites, required context, or suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
创建 Namespace。format 仅支持 properties、xml、json、yml、yaml。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| name | Yes | ||
| format | Yes | ||
| isPublic | Yes | ||
| dataChangeCreatedBy | Yes | ||
| comment | No | 可选 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only mentions the format constraint but omits potential side effects (e.g., idempotency, permission requirements, behavior on duplicate namespace).
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 overly terse at two sentences, sacrificing essential information for brevity. It lacks detail on parameter roles, return values, or error handling, making it under-specified rather than effectively concise.
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 six parameters (five required), no output schema, and minimal description, the tool definition is inadequate. Missing return value specification and error conditions leave the agent uncertain about expected outcomes.
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 only 17%, and the description does not compensate. It only repeats the enum values for format, leaving critical required parameters like appId, name, isPublic, and dataChangeCreatedBy undocumented.
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 '创建 Namespace' which clearly identifies the action and resource. The format limitation is explicitly mentioned, distinguishing it from sibling create tools like create_app or create_cluster.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
删除配置项。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes | ||
| key | Yes | ||
| operator | Yes | 删除操作者，域账号 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'delete,' implying destruction, but does not describe permanence, cascading effects, or required permissions.
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?
While very short, the description is under-specified. It fails to provide essential context, making it insufficiently informative despite its brevity.
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 6 required parameters, no output schema, and no annotations, the minimal description is completely inadequate for an agent to understand usage and outcomes.
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 17% (only 1 of 6 parameters has description). The tool description adds no parameter-level meaning, leaving agents uninformed about required fields.
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 'Delete configuration item,' clearly indicating the verb and resource. It distinguishes from sibling tools (none have delete), but lacks additional context about the scope or type of item.
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?
No guidance is provided on when to use delete_item versus alternatives, such as prerequisites or consequences compared to other modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取应用的环境与集群信息。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | 应用 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description lacks behavioral details such as required permissions, rate limits, response structure, or side effects. For a tool with zero annotation coverage, the description provides minimal transparency beyond the basic action.
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 a single, direct sentence that immediately conveys the tool's purpose. It is front-loaded and contains no unnecessary words or fluff.
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 the absence of an output schema, the description should provide more context about what '环境与集群信息' (environment and cluster information) includes. The tool retrieves data, but the agent cannot infer the structure or scope of the response. This lack of completeness limits effective usage.
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 single parameter 'appId' is described in the schema as '应用 ID' (App ID). With 100% schema description coverage, the schema already adequately documents the parameter. The tool description does not add additional semantic value beyond what is in the schema, so a baseline score of 3 is appropriate.
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's purpose: '获取应用的环境与集群信息' (get application environment and cluster information). It is a specific verb+resource combination, and the tool name aligns well with this purpose. Among siblings, it is distinct from 'get_cluster' by focusing on an app's environments and clusters.
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?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives like 'get_cluster' or 'list_apps', nor does it mention prerequisites or context. This leaves the agent without guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取集群详情。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | 应用 ID | |
| env | Yes | 环境，如 FAT、UAT、PRO | |
| clusterName | Yes | 集群名，一般 default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It does not disclose behavioral traits such as whether the tool is idempotent, what happens if the cluster does not exist, or any permission requirements. Only the basic read operation is implied.
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 extremely concise (a single sentence). While it is not verbose, it could usefully include more context without becoming lengthy. It is not optimally structured for quick scanning.
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 the absence of an output schema, the description should at least indicate what information is returned. It does not, nor does it address error scenarios or edge cases. The tool's simplicity does not excuse the lack of completeness.
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 coverage is 100%, so the schema already describes all three parameters. The description adds no additional meaning beyond the schema, which is adequate but not enhanced. Baseline score of 3 is appropriate.
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 retrieves cluster details, which is a specific verb and resource. It is distinct from sibling tools like get_app_env_clusters (which lists clusters) and create_cluster. However, it could be more explicit about what 'details' entail.
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?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives like get_app_env_clusters, nor does it specify prerequisites or suitable contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取单个配置项。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes | ||
| key | Yes | 配置 key；非 properties 格式固定为 content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'get a single configuration item,' revealing nothing about permissions, side effects, or return characteristics. The tool likely reads data, but this is not explicitly stated.
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 extremely concise (one short sentence) but fails to convey needed information. Brevity here sacrifices clarity and utility, making it under-specified rather than efficiently concise.
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 5 required parameters and no output schema, the description is drastically incomplete. It does not explain what a 'configuration item' is, what the response looks like, or any error conditions. The tool's complexity demands a richer description.
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 only 20% (only 'key' has a description). The tool description adds no parameter meaning. The four other required parameters (appId, env, clusterName, namespaceName) are left completely unexplained, which is inadequate given the low 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 '获取单个配置项' clearly states the tool retrieves a single configuration item. The verb and resource are specific, and the sibling tools (e.g., list_items, get_namespace) help distinguish its purpose.
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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like list_items or get_latest_release, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 Namespace 当前生效的已发布配置。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the operation is read-only, what constitutes 'currently effective', or any side effects. The description is minimal and leaves behavior largely unspecified.
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 a single sentence, which is concise, but it lacks necessary details to be fully effective. It is front-loaded with the core action but sacrifices completeness for brevity.
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 the tool has 4 required parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the return value, how to use it in a workflow, or any constraints like parameter dependencies.
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 0%, placing the full burden on the description to explain parameters. The description provides no information about the four required parameters ('appId', 'env', 'clusterName', 'namespaceName'), relying solely on their names for 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 tool's purpose: retrieving the currently effective published configuration for a Namespace. It uses a specific verb-resource combination ('get the... configuration') and distinguishes from siblings like 'get_item' or 'get_namespace' by specifying 'latest release'.
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?
No explicit guidelines on when to use this tool versus alternatives. The context of sibling tools suggests it is for retrieving the active release configuration, but there is no mention of when not to use it or which sibling to choose instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定 Namespace 详情。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes | 如 application、FX.apollo；非 properties 需带后缀如 sample.yml |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says '获取详情' (get details), which implies a read operation, but does not state side effects, required permissions, or what constitutes 'details.' The description lacks transparency about response format or potential errors.
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 a single concise sentence. However, it is too brief and lacks essential details, so brevity comes at the cost of informativeness. Every sentence should earn its place; here, it does not provide enough 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?
Given 4 required parameters, no output schema, no annotations, and a 25% schema coverage, the description is severely incomplete. It does not explain what details are returned, how to construct the parameters, or any constraints. A minimal viable description would at least define the parameters and output.
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 25% (only namespaceName has a description). The tool description adds no parameter information, failing to compensate for the low coverage. Parameters like appId and env are left entirely undocumented in both schema and description, making it hard for the agent to know how to use them.
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 retrieves details of a namespace ('获取指定 Namespace 详情'). The verb '获取' (get) and resource 'Namespace 详情' are specific, but it does not differentiate from siblings like get_namespace_lock or list_namespaces, which also relate to namespaces.
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?
No guidance on when to use this tool versus alternatives. There are no prerequisites, exclusions, or context about typical use cases. Sibling tools like create_namespace or list_namespaces offer related functionality, but the description does not clarify when get_namespace should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 Namespace 当前编辑人/锁状态。PRO 环境有编辑锁定规则。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It describes the purpose but fails to indicate whether this is a read-only operation, if special permissions are needed, or what the response format is. The mention of PRO environment hints at a rule but does not clarify behavior.
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 very concise, consisting of two short sentences. It is front-loaded with the main purpose. However, the brevity sacrifices necessary detail.
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 the lack of output schema, annotations, and parameter descriptions, the description is incomplete. It does not provide enough context for an AI agent to correctly select and invoke this tool, especially among sibling tools like 'get_namespace'.
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 4 required parameters with 0% schema description coverage. The description does not explain the meaning or expected values for any of these parameters (appId, env, clusterName, namespaceName).
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 it retrieves the current editor/lock status of a Namespace and mentions the PRO environment editing lock rules. This is a specific verb and resource, but it does not differentiate from the sibling tool 'get_namespace', which might have overlapping functionality.
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?
No guidance on when to use this tool versus alternatives like 'get_namespace' or other lock-related tools. There is no mention of prerequisites, contexts where this tool is appropriate, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取应用列表。可选 appIds 参数（逗号分隔）过滤，为空则返回所有应用。
| Name | Required | Description | Default |
|---|---|---|---|
| appIds | No | appId 列表，逗号分隔，可选 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses basic behavior (filtering and default listing all apps) but lacks details like pagination, ordering, or any side effects. Since no annotations are provided, the description carries the burden fully, and this is adequate but minimal.
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 sentence that conveys purpose and parameter usage without unnecessary words, perfectly 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?
Given a simple tool with one optional parameter and no output schema, the description fully explains what the tool does and how to use it. No gaps remain.
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 schema already describes appIds as a comma-separated list, but the description adds crucial context: leaving it empty returns all apps. This extra behavioral note justifies a slight boost above the baseline of 3.
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 it retrieves a list of applications (获取应用列表), and distinguishes from sibling tools like create_app, get_item, list_items, etc., which have different purposes.
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 explains how to use the optional appIds parameter for filtering and the default behavior when omitted. However, it doesn't explicitly mention when not to use this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分页获取 Namespace 下的配置项。需 Apollo 版本>=2.1.0。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes | ||
| page | No | 页码，默认 0 | |
| size | No | 页大小，默认 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注释，描述未披露行为特征，如是否只读、是否需要认证、返回格式等。仅提到分页，但对副作用和前提条件无任何说明。
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?
描述极简，一句完成，但牺牲了关键信息。可以适当扩展而不破坏简洁性，因此评为中等。
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?
6个参数、无输出模式、无注释，描述仅覆盖版本要求和分页概念，未能提供调用该工具所需的完整上下文，如返回格式、错误处理、认证要求等。
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?
模式描述覆盖率仅33%（page和size有描述），描述未额外解释必需参数（appId、env、clusterName、namespaceName），导致参数语义严重不足。
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?
描述明确说明工具用于分页获取Namespace下的配置项，动词和资源清晰。但未与兄弟工具如'get_item'或'list_namespaces'进行区分，因此略降一分。
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?
描述仅包含版本要求，未提供何时使用此工具而非兄弟工具（如'get_item'获取单个项）的指导，也未说明不适用场景。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取集群下所有 Namespace 及配置项。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | 默认 default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the operation is read-only, idempotent, or requires any special permissions. The mention of '配置项' (configuration items) implies additional data but lacks clarity on what is returned.
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 a single sentence, which is concise but lacks structure. It does not front-load key information or break down details for clarity.
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 three required parameters, no output schema, and no annotations, the description is incomplete. It does not explain the output format or how to interpret results, and the ambiguity of '配置项' reduces completeness.
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 coverage is only 33% (only clusterName has a brief description). The required parameters appId and env have no description, and the description does not elaborate on their meanings or expected values.
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 '获取集群下所有 Namespace 及配置项' which clearly indicates the tool lists all namespaces and configuration items under a cluster. The verb '获取' (get) and resource 'Namespace' are specific, and it distinguishes from sibling tools like get_namespace which retrieves a single namespace.
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?
No guidance is provided on when to use this tool versus alternatives such as get_namespace for a single namespace or list_apps for applications. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
发布配置。releaseTitle 不超过 64 字符。PRO 环境可能要求发布人与编辑人不同。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes | ||
| releaseTitle | Yes | ||
| releasedBy | Yes | ||
| releaseComment | No | 可选 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It mentions a length limit and a conditional requirement, but omits critical details like whether the operation is idempotent, if it overwrites existing releases, or any destructive side effects.
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 extremely concise with two short sentences, front-loading the purpose. Every word adds value, and there is no superfluous text.
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?
The tool has 7 parameters and no output schema. The description is minimal, missing information on return values, error conditions, prerequisites (e.g., namespace must exist), and step-by-step guidance for a publish workflow.
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 only 14% (only releaseComment has a description). The tool description adds meaning for releaseTitle (max 64 chars) and hints at releasedBy constraints, but does not clarify the semantics of other required parameters like appId, env, clusterName, or namespaceName.
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's purpose as 'publish configuration' (发布配置), using a specific verb and resource. However, it does not distinguish it from sibling tools like rollback_release or create_item, which are related but different actions.
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?
No explicit guidance on when to use this tool versus alternatives. The description only provides constraints (releaseTitle length and PRO environment requirement) but no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
回滚到指定版本。releaseId 为发布记录 ID，从 get_latest_release 返回的 id 字段获取。
| Name | Required | Description | Default |
|---|---|---|---|
| env | Yes | ||
| releaseId | Yes | 发布记录 ID，从 get_latest_release 返回的 id 字段获取 | |
| operator | Yes | 操作者，域账号 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'rollback' which implies a state change, but lacks disclosure of destructive effects, prerequisites, or any behavioral traits beyond the name.
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 concise sentences, no wasted words. Front-loaded with the primary action. Efficient for a simple tool.
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 three required parameters and no output schema or annotations, the description is incomplete. It does not explain return values, error conditions, or prerequisites like the need for a previous release. A rollback is a significant action, and the lack of context leaves the agent underinformed.
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 67% (2/3 params described). The description adds minimal extra context for releaseId (where to get it), but adds no meaning for env or operator. Baseline 3 since coverage is high but description does not fully compensate for missing param descriptions.
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 'rollback' and the resource 'release', with a specific verb and resource. It also references a sibling tool (get_latest_release) for obtaining the required releaseId, distinguishing itself from publish_release.
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 implies usage by explaining where to get the releaseId (from get_latest_release), but does not provide explicit guidance on when to use rollback vs alternatives like publish_release, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
修改配置项。createIfNotExists 为 true 时不存在则创建，此时 dataChangeCreatedBy 必填。
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | ||
| env | Yes | ||
| clusterName | Yes | ||
| namespaceName | Yes | ||
| key | Yes | ||
| value | Yes | ||
| dataChangeLastModifiedBy | Yes | ||
| createIfNotExists | No | 可选 | |
| dataChangeCreatedBy | No | createIfNotExists 时必填 | |
| comment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the conditional creation behavior and required parameter dependency, but lacks information on side effects, authorization needs, idempotency, or error states. Minimal behavioral context.
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?
Extremely concise: two sentences that convey the core purpose and a key conditional rule. No wasted words; front-loaded with the primary action.
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 the complexity (10 parameters, no output schema, no annotations), the description is insufficient. It does not explain parameter semantics for most fields, provide usage examples, or clarify response behavior. Large gaps remain.
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 coverage is low (20%); only two parameters have descriptions. The description adds meaning by explaining the conditional creation logic and the dependency on dataChangeCreatedBy, but leaves the other eight parameters completely undocumented.
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?
Description states it modifies a configuration item, which is clear and actionable. It also explains the conditional creation behavior. However, it does not explicitly distinguish from sibling tools like create_item or delete_item, which would help the agent choose correctly.
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?
No guidance on when to use this tool versus alternatives. It does not mention that create_item might be more appropriate for pure creation, nor does it provide context on prerequisites or limitations.
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. Dates show when Glama detected each change.
v1.0.0create_appcreate_clustercreate_itemcreate_namespacedelete_itemget_app_env_clustersget_clusterget_itemget_latest_releaseget_namespaceget_namespace_locklist_appslist_itemslist_namespacespublish_releaserollback_releaseupdate_itemEach tool targets a distinct entity or action: apps, clusters, namespaces, items, and releases are clearly separated, with no overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_app, get_namespace, list_items), with no mixing of conventions.
17 tools is slightly above the ideal range of 3-15, but still reasonable for a configuration management platform covering multiple entity types.
The tool surface covers core operations for apps, clusters, namespaces, items, and releases, but lacks update/delete for apps, clusters, and namespaces, which are notable gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Build and manage Chipp AI apps: prompts, knowledge, custom actions, and chat with your apps.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iceycn/mcp-server-apollo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
