Loading ToolBench
Model Context Protocol server for e-commerce operations with weather integration
The Q-CLI MCP server has severe definition quality issues. Of 5 registered tools, only 2 are unique (get_alerts and get_forecast are duplicated). Tool descriptions are present but generic. Critically, parameter descriptions are vague or unhelpful (e.g., 'skjun' for say_hello's state parameter has no semantic meaning). Input schemas are visible but lack proper type definitions for some fields and missing descriptions on all parameters in say_hello. The say_hello tool description ('Get message from for Hello mcp.') contains a grammatical error and fails to explain what 'state' controls or what output to expect. No tool documents its return schema. Error handling is absent, no recovery guidance. The codebase provided (ecommerce_server.py) does not appear to match the MCP server implementation, creating confusion about the actual tool definitions.
Get weather alerts for a US state.
Get weather alerts for a US state.
Get weather forecast for a location.
Get weather forecast for a location.
Get message from for Hello mcp.
Duplicate tool registrations: get_alerts and get_forecast appear twice in the tool list. This wastes LLM reasoning cycles and violates the single-responsibility principle. Duplicates must be removed or differentiated (e.g., get_alerts_federal vs get_alerts_local).
Parameter description 'skjun' for say_hello's state parameter is meaningless gibberish. It does not explain what state controls, what values are valid, or what the tool returns. LLMs cannot infer intent from nonsense descriptions.
say_hello description 'Get message from for Hello mcp.' contains a grammar error ('from for') and fails to state what the tool does, when to use it, or what the output structure is. Descriptions must be complete and LLM-optimized.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
No tool documents its return/output schema. LLMs need to know what fields and types to expect so they can plan downstream tool calls and extract the right data. All tools must include documented output schemas.
No error handling or recovery guidance. If a weather API call fails or a state code is invalid, there is no documented error message or guidance for what the LLM should try next. Errors must include actionable recovery hints.
get_alerts and get_forecast descriptions lack actionable context. 'Get weather alerts for a US state' does not explain when this tool is preferred over get_forecast, what data structure is returned, or pagination behavior. Descriptions must be 50-200 characters and include all key details.
Parameter 'state' for get_alerts mentions 'Two-letter US state code (e.g. CA, NY)' which includes example values in the description. LLMs tend to reuse examples literally. Use an enum constraint instead: {"type": "string", "enum": ["CA", "NY", ...]} to be machine-parseable.
Source code provided (ecommerce_server.py) does not match the MCP server tool definitions. The code shown is an e-commerce HTTP handler unrelated to weather tools. This makes it impossible to verify the actual tool implementations, parameter validation, or error handling logic.