Loading ToolBench
A multi-module Spring Boot application providing MCP servers for infrastructure monitoring (monitor module) and RAG-based knowledge base retrieval (rag module). The application-agent module consumes these tools via MCP client.
This server has severe definition quality issues. Only 2 tools are exposed, and both lack critical documentation. Tool names are non-standard (neither starts with an action verb), parameter descriptions are minimal or absent, and input schemas are incomplete. The 'rag-agent' tool has one parameter with minimal description. Neither tool has documented output schemas, error handling guidance, or actionable descriptions that would help an LLM decide when to call them. The descriptions are present but generic and lack the specificity required by production patterns.
Provides responses from the RAG agent, which retrieves information from the corporate knowledge base.
Provides the runtime status of the infrastructure, system, or application, including server status, disk space information, and API usage metrics. Use this tool to check if the system is UP, DOWN, or CAIDO, monitor service quality, and get infrastructure runtime information.
Tool names do not start with action verbs. 'system-status' and 'rag-agent' are nouns, not verbs. LLMs rely on verb-prefixed names to infer intent. Should be 'get_system_status' and 'query_knowledge_base' or 'get_rag_response'.
Tool 'system-status' has an empty input schema ({}). No parameters are documented, but the description hints at multiple capabilities (server status, disk space, API metrics), suggesting the tool does multiple things and should be split.
No output schemas are documented for either tool. LLMs cannot plan downstream calls or extract data without knowing what fields the response will contain. Critical for chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 25 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Parameter description for 'rag-agent.userMessage' is vague: 'The user input, to determine it requires information from the corporate knowledge base.' Does not explain format, length constraints, or what 'requiring information' means. Ambiguous descriptions lead to LLM misuse.
Tool descriptions lack actionable guidance on WHEN to call each tool and WHAT to expect. 'system-status' description lists features but does not explain when an LLM should invoke it instead of calling a specialized monitoring tool. 'rag-agent' description does not explain when to route queries to the knowledge base.
No error handling guidance. Neither tool describes what happens on failure, what errors are retryable, or how an LLM should recover. Missing recovery guides violate the error-handling pattern.
'system-status' description uses generic term 'CAIDO' (likely a typo for 'DEGRADED' or similar), which is unexplained and not a standard status. Unclear status values confuse LLMs about system health.
Tool composition issue: 'system-status' conflates multiple responsibilities (server status, disk space, API metrics). Should be split into get_server_status, get_disk_usage, get_api_metrics so the agent can compose as needed.