mcp-nacos

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.0
Disambiguation4/5
Most tools target distinct resource+action pairs (e.g., list vs get namespace, get config vs list configs). However, the three history-related tools (list_config_history, get_config_history, get_config_previous) are closely related and could confuse agents, especially regarding which ID to use, though descriptions provide some clarity.
Naming Consistency5/5
All tool names follow a consistent 'nacos_<verb>_<noun>' pattern with verbs limited to list and get. The naming is predictable, snake_case throughout, and clearly indicates each tool's purpose.
Tool Count5/5
With 7 tools, the server is well-scoped for a Nacos configuration management interface. Each tool covers a necessary read or history operation, and the count is within the typical 3-15 range.
Completeness3/5
The tool set covers namespace and config read operations, including list/get and config history, but lacks any write operations such as create, update, or delete config. This is a notable gap for a tool named 'mcp-nacos' and will cause agent failures if configuration changes are attempted.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the API endpoints and notes that it returns the complete config content, but does not discuss error behavior, auth needs, or rate limits. This is acceptable given 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose. The listing of three API versions adds some extra detail that may not be essential for an AI agent, but it is structured and not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and clear annotations, the description sufficiently covers the tool's function and key parameter. It could mention prerequisites like the nid being valid, but the overall completeness is good for a simple read-only retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already well-documented. The description highlights nid as the key identifier, which aligns with the schema, but adds little beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool queries a specific historical change record and returns the complete configuration content for a given nid. This is specific and distinguishes it from sibling tools like nacos_list_config_history (which lists records) and nacos_get_config_previous (which likely retrieves a previous version).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you have a nid and need the full content of that historical version. However, it does not explicitly mention alternatives or when-not-to-use compared to similar tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by listing the specific OpenAPI endpoints (v1, v2, v3) and the paginated response fields, providing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-purpose opening sentence, a bullet list of endpoint mappings, and a final note on return content. It is front-loaded and every sentence earns its place without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple read-only list operation, especially with detailed parameter schemas and strong annotations. It could be improved by noting usage distinctions from sibling tools, but it already covers the function, pagination, and return fields, making it complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, each with clear descriptions. The tool description itself does not add any parameter semantics beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '查询配置历史版本列表' (query configuration history version list), identifying the verb (query) and resource (config history versions). It also specifies that it returns a paginated list with fields like id, opType, operator, and time, which distinguishes it from single-history retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving a list of historical versions but does not provide explicit when-to-use guidance or alternatives. It does not differentiate from sibling tools like get_config_history or get_config_previous, leaving the agent to infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by clarifying that it returns the complete config content of the previous version and that config_id corresponds to the id field in the history API. It also lists the three API endpoint variants, which is extra context beyond the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose, followed by a compact endpoint list and a behavior statement. The endpoint list might be slightly over-detailed for invocation, but it is not wasteful. Overall, it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, output behavior, and parameter semantics, and an output schema exists for return values. It does not explicitly contrast with sibling history/lookup tools, but for a read-only query with strong annotations and schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds crucial clarification that config_id is '配置存储 ID（对应历史接口中的 id 字段）' and is required, reinforcing its role beyond the generic schema description. This extra semantic context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询配置最新状态的前一次变更历史' (query the previous change history of the latest config state) and specifies that it returns the complete content of the previous version. This is specific and distinguishes it from siblings like nacos_get_config (current config) and nacos_get_config_history (specific history version).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing what the tool does (retrieve last previous version), but it does not explicitly state when to use this over alternatives such as nacos_get_config_history or nacos_list_config_history. No when-not guidance or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context about public namespace normalization across versions ('传 'public' 或空串都可查到，底层统一用空串') and version-specific endpoint behavior, which goes 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear topic sentences and bullet-pointed version details. It is moderately concise, though it somewhat duplicates normalization info already in the schema. Overall, every sentence contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich output schema and strong annotations. The description provides sufficient context for a single-parameter read operation, including version compatibility, normalization behavior, and return value summary. Missing edge-case behavior (e.g., not found) but not critical for a read-only tool with this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description repeats normalization information already present in the schema's parameter description (priority, 'public' handling). It does not add new parameter semantics beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '查询单个命名空间详情' (query single namespace details), which is a specific verb+resource action. It distinguishes from sibling 'nacos_list_namespaces' by focusing on a single namespace and mentions returning quota and usage details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for retrieving a single namespace's details. It provides version-specific API notes (v1/v2/v3) and mentions that v1 uses a filtered list simulation, implicitly differentiating from the list tool. However, it lacks an explicit 'use this instead of list_namespaces' statement or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds value by mapping to Nacos OpenAPI v1/v2/v3 endpoints with different params, indicating the tool's internal implementation and that it returns config content. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and uses each line effectively. It lists API versions and parameters without redundancy, earning every sentence's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple retrieval operation with 4 parameters and an output schema (per signal), so the description need not detail return values. It covers the key uniqueness, API version mapping, and parameter precedence, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3. The description enriches parameter understanding by explaining the unique key combination and mapping v1 'tenant' to v2 'namespaceId', adding contextual meaning beyond the schema's labels and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Nacos configuration content, with a specific verb '获取' and resource '配置内容'. It uniquely identifies a config by dataId, group, and namespace, which distinguishes it from sibling tools that list configs or retrieve history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want a specific config and know its dataId/group/namespace, but it does not explicitly mention alternatives or exclusions. No guidance is given on when to use this tool over sibling tools like nacos_list_configs or history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds substantial behavioral context: search=blur does not auto-wildcard, substrings don't match unless wildcards are explicit, and the return includes a total count. It also discloses version-specific API endpoints. This goes well beyond minimal disclosure and enriches the agent's mental model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line purpose, a bulleted API mapping, a separate matching-semantics paragraph, and a clear return format statement. Every sentence serves a purpose, and the length is appropriate for the tool's complexity. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, filtering capabilities, matching behavior, return format, and version support. With an output schema present, it provides everything an agent needs to invoke the tool correctly and interpret results. No gaps detected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all 8 parameters, including detailed descriptions of wildcard behavior for data_id and group_name. The description's matching semantics section essentially reiterates this schema information without adding new parameter-specific meaning. Thus the baseline of 3 applies, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the configuration list under a namespace, using the specific verb '查询' and resource '配置列表'. It differentiates from siblings like nacos_get_config by explicitly noting it returns metadata (data_id, group_name) and excludes config content, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it returns metadata only, not content, implying it is for listing rather than fetching full configs. It also explains matching semantics for fuzzy vs exact search. However, it does not explicitly name alternatives or state exclusions (e.g., 'use nacos_get_config for content'), so it misses the highest bar for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds value beyond annotations by specifying the exact API endpoints (v1/v2/v3) and clarifying the return content (includes public namespace, quota, and usage). This gives the agent a more concrete picture of what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact and front-loaded with the core purpose, followed by structured endpoint references and a clear note on return content. No redundant sentences; each part adds context without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is complete: it states what is listed, the namespace scope, and what information is returned. An output schema exists to define the exact return structure, so the description does not need to duplicate that. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The description correctly avoids fabricating parameter explanations. Baseline 4 is appropriate because parameter semantics are trivially covered by the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: '查询命名空间列表' (query namespace list) and specifies the resource. It distinguishes from sibling nacos_get_namespace by enumerating all namespaces including public, and mentions quota/usage. The verb and scope are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use to retrieve all namespaces from the current Nacos instance, with added details about public namespace inclusion and quota/usage. It does not explicitly mention when not to use it or name alternatives, but the scope is sufficiently clear given the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-nacos MCP server](https://glama.ai/mcp/servers/zhouweico/mcp-nacos/badges/card.svg)](https://glama.ai/mcp/servers/zhouweico/mcp-nacos)

Score Badge

Copy to your README.md:

[![mcp-nacos MCP server](https://glama.ai/mcp/servers/zhouweico/mcp-nacos/badges/score.svg)](https://glama.ai/mcp/servers/zhouweico/mcp-nacos)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhouweico/mcp-nacos'

If you have feedback or need assistance with the MCP directory API, please join our Discord server