Loading ToolBench
Lightweight MCP server that lets AI agents read Nacos 2.x configs and services over the v1 Open API.
Five read-only tools with clear verb-noun naming (list_*, get_*, search_*). All tools have descriptions (50-200 chars, well-optimized for LLM selection). Input schemas present with type definitions and parameter descriptions. Output is JSON-serialized and structured. Key strength: descriptions include dependency hints ('Call this FIRST') and use cases. Weakness: no output schema documentation (LLMs must infer structure from examples); no error handling guidance; no input validation constraints (e.g., pageSize capped at 100 but not enforced in schema); no enum constraints for optional parameters.
Read the raw content of a Nacos config. Call this BEFORE writing a new @Value / @ConfigurationProperties binding, a Feign target URL, or any config key — to confirm what is actually maintained in Nacos instead of guessing or duplicating an existing value.
List instances of a registered service. Useful to verify a service is alive and see its IPs/ports/metadata before writing integration code that depends on it.
List namespaces in the Nacos cluster with config counts and quotas. Call this FIRST when you only know a project/environment name — it maps display names (e.g. "test", "prod") to namespace ids, which other tools take as their `namespace` argument. Returns metadata only: namespaceId, name, configCount, quota.
List services registered in a Nacos namespace. Call this before wiring up a new Feign / Dubbo reference to confirm the target service is actually registered, and to copy its exact service name.
List / blur-search Nacos configs by dataId and group. Leave both patterns blank to list every config in the namespace. Use this to check whether a config key already exists before creating a new one, and to discover the dataId/group naming conventions a project follows. Returns metadata only (dataId, group, type, md5, lastModified). Use get_config to read a specific config's full content.
No output schema documentation. LLMs must infer response structure from descriptions alone. E.g., list_namespaces returns 'namespaceId, name, configCount, quota' but no formal schema defines field types, nesting, or array structure.
Input validation constraints not enforced in schema. pageSize capped at 100 in code (search_configs line 'page_size = min(max(pageSize, 1), 100)') but not declared in JSON Schema. LLMs may pass invalid values; server silently clamps them instead of rejecting with actionable error.
No error handling guidance. Tools return JSON on success but no documented error responses. If Nacos API fails (auth, network, invalid config), LLM receives raw exception or HTTP error with no recovery hint (e.g., 'Try list_namespaces first to verify namespace exists').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Optional parameters lack enum constraints. 'namespace' is optional string with no validation. LLM may pass arbitrary strings; server silently defaults to configured namespace instead of rejecting invalid IDs with guidance.
No tool annotations (readOnlyHint, idempotentHint). All tools are read-only and safe to retry, but FastMCP does not expose these hints. Clients cannot infer safety properties without reading descriptions.