Loading ToolBench
Project-aware, read-only Nacos MCP server for Spring Cloud repos: auto-discovers every environment from your application/bootstrap configs, no manual setup.
This server exposes 7 tools for querying Nacos configuration and service registries in Spring Cloud environments. All tools are read-only (appropriate for the domain), but definition quality is mixed. Tool naming follows verb-noun convention correctly (get_, list_, search_, diff_). However, descriptions are generally adequate but brief (averaging ~80 characters), and critically, NO INPUT SCHEMAS are visible in the provided code, only descriptions of parameters. The code shows tool registration via MCP's CallToolRequest handler, but the actual JSON Schema definitions for input parameters are not shown in the source excerpt. This is a HARD CAP issue: without visible schemas, schema scores must be 0. Parameter descriptions exist in the descriptions, but are embedded in prose rather than as formal JSON Schema objects with type, description, and constraint declarations. Output schemas are completely undocumented. Error handling is minimal, no recovery guidance or error categorization. Composition is sound (tools are single-purpose), but the lack of formalized input schemas and output documentation significantly limits LLM reasoning quality.
Compare two configs (by data-id, group, and two environments) and return a unified diff.
Fetch a single config from Nacos by data-id and group. Returns the raw config content.
List all config data-ids in a Nacos group for a given environment. Returns a list of data-ids.
List all discovered environments (dev, test, pre, prod, etc.) in the current Spring Cloud repository.
List all instances of a given service in Nacos. Returns instance details (IP, port, metadata, health status, etc.).
List all services registered in Nacos for a given environment and group. Returns a list of service names.
Search for configs in Nacos by data-id and group. Supports wildcards and partial matches. Returns matching data-ids.
NO VISIBLE INPUT SCHEMAS. Tool parameters are described in prose strings (e.g., 'dataId', 'group', 'env') but no formal JSON Schema definitions are present in the provided code. The MCP server must register tools with explicit inputSchema objects containing 'type', 'properties', 'required', and per-property 'description' fields. This forces LLMs to infer valid parameter sets from natural language alone, increasing errors.
NO OUTPUT SCHEMAS DOCUMENTED. The code shows tools return results (e.g., 'Returns a list of data-ids', 'Returns instance details'), but no formal output schema is declared. LLMs cannot plan downstream tool calls or extract specific fields when they don't know the structure of the response.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
PARAMETERS LACK ENUM/FORMAT CONSTRAINTS. Parameters like 'env', 'group', and 'mask' have prose descriptions but no formal type constraints, enums, or ranges in visible schema. For example, 'mask' is a boolean with default=true, but there is no explicit boolean type declaration in a schema. Enum values for 'env' (dev, prod, test, pre) are mentioned in descriptions but not formalized.
MINIMAL ERROR HANDLING & RECOVERY GUIDANCE. No explicit error messages or recovery suggestions visible in the server code (excerpt shows HTTP calls and YAML parsing, but error handling is silent or generic). If a Nacos fetch fails, the agent has no guidance on what to try next (e.g., 'Check if the environment exists. Call list_envs() to see available options.').
BRIEF DESCRIPTIONS (avg ~80 chars). Most tool descriptions are concise (e.g., 'Fetch a single config from Nacos...', 'List all config data-ids in a Nacos group...') but lack explicit guidance on WHEN to use each tool vs. similar ones. E.g., when would an agent choose search_configs over list_configs? What's the performance difference? Descriptions should include selection criteria.
NO PAGINATION PARAMETERS. Tools like list_configs, list_services, and list_instances return lists but no pagination parameters (limit, offset, page_size) are visible. If a Nacos namespace has thousands of configs, the response could be enormous, exhausting token budget. Baseline: paginated tools should accept limit (1 - 100, default 20) and offset/cursor parameters.
PARAMETER NAME AMBIGUITY: 'env' vs. 'environment'. Some descriptions say 'Environment name (e.g. dev, prod)' and default to 'uses the first discovered environment'. But there's no enum constraint showing valid environment names. Agents cannot validate their choice. list_envs() helps, but it should be the first call, tooling should guide this explicitly.