Loading ToolBench
MCP server providing tools for arithmetic operations, weather queries, and resource access
This MCP server demonstrates foundational tool structure but falls significantly short of production standards. All 5 tools have descriptions and basic schemas, but lack depth, parameter documentation, error handling, and composition clarity. The server mixes tool/resource/prompt concerns without clear separation. Naming is action-verb based (positive), but parameter descriptions are minimal or missing. No output schemas are documented. Error handling is absent. The server functions as a learning demo but would not pass code review for production deployment.
Add two numbers
Get current temperature of a city
Get tax code
Review this sentence, remove any personal information
Say hi to people with name
Tool get_ma_so_thue registered as resource (not tool) with no meaningful description beyond docstring 'Get tax code'. This violates pattern:tool, if it's meant to be invoked, register as a tool with clear input schema and output documentation. The description is under 20 characters of meaningful content.
Parameter descriptions are either missing or trivial. 'city_name' in get_current_temperature_by_city has description 'Name of the city', adequate but not LLM-optimized. No constraints (format, length, examples) provided. Per pattern:tool-description, every parameter needs a non-empty, actionable description explaining what it controls and any constraints.
No output schemas documented for any tool. Tools return simple types (int, str) but LLMs need to know field names and structure for downstream chaining. E.g., add returns an int, but is it the sum? The result? What if the operation fails? Per pattern:tool, document the return type structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool naming is ambiguous or incomplete. 'get_ma_so_thue' is in Vietnamese and opaque to English-speaking LLMs, should be 'get_tax_code'. 'say_hi' is imperative but not a query tool; 'generate_greeting' would be clearer. Per pattern:tool, tool names must be self-documenting in English, starting with an action verb.
Resources vs. tools vs. prompts are conflated. 'get_ma_so_thue' and 'say_hi' are registered as resources (@mcp.resource) with URI patterns, not tools. 'review_sentence' is registered as a prompt, not a tool. This breaks the tool/resource boundary, if the intent is to invoke these as actions, they should be registered as tools with proper schemas.
No error handling or recovery guidance. If add() receives non-integer inputs, get_current_temperature_by_city receives an invalid city name, or say_hi receives an empty string, the tools will likely fail silently or crash. Per pattern:recovery-guide, error responses must tell the LLM what to do next.
No input validation or constraints. 'a' and 'b' in add() are typed as int but unbounded, the LLM could pass integers outside hardware/API limits. 'city_name' accepts any string with no validation. Per pattern:constrained-input, constrain inputs (enums for sets, ranges for numbers, regex patterns for strings) and document constraints in descriptions.
Temperature tool returns hardcoded string '20 degrees celsius', not a real API call. This is acceptable for a demo but the description 'Get current temperature of a city' promises live data. Either implement real API integration or clarify that this is a mock tool.