Loading ToolBench
MCP Server with tools for weather, calculations, and pet store operations
This server provides 5 tools with explicit schemas and descriptions, but exhibits significant quality gaps relative to production baselines. Tool naming follows verb conventions (get_*, find_*, add_*), but descriptions lack contextual depth and actionability. Schemas are present and typed, but parameter descriptions are minimal or missing entirely. Output schemas are not documented. Error handling code exists (ErrorHandler utility) but error guidance patterns are not evident in tool definitions. The server demonstrates competent structure but falls short of A+ production standards.
Add a new pet to the store
Evaluate a mathematical expression
Finds Pets by status
Find pet by ID
Get current weather information for a city
Tool descriptions lack actionable context. 'Get current weather information for a city' (57 chars) is generic and does not answer WHEN to use this tool or WHAT it returns. LLMs cannot distinguish this from a weather forecast API that returns historical data.
Parameter descriptions are missing or trivial. 'city' parameter in get_weather has only 'City name', no format constraints, no guidance on what happens if the city is ambiguous (e.g., 'Springfield'). 'expression' in calculate has no examples of valid syntax (infix? postfix?) or boundary cases.
getPetById uses camelCase naming ('getPetById') inconsistent with the snake_case convention used by get_weather, calculate, findPetsByStatus. LLMs are sensitive to naming patterns, inconsistency causes parsing ambiguity.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
No output schema documentation. Tools return results but LLMs cannot see what fields to expect. get_weather returns weather data, but is it {temp: number, condition: string}? {current: {temp}, forecast: []}? Without documented output, agents cannot chain tools or extract the right data.
addPet lacks state-modification guidance in its description. 'Add a new pet to the store' does not clarify: Is this idempotent? Can I retry safely? Will duplicate pets be created? Agents need to know the idempotency semantics and whether to confirm before executing.
findPetsByStatus returns no pagination metadata. If there are 500 matching pets, does the tool return all 500? No limit, offset, or next_cursor documented. Large result sets blow context windows and degrade LLM reasoning.
No error recovery guidance in tool definitions. ErrorHandler utility exists in code but tool descriptions do not state what errors are possible, when to retry, or what the LLM should do if a call fails. A missing city in get_weather should suggest 'Try search_cities() for a list of valid cities.'
addPet parameter 'status' has enum ['available', 'pending', 'sold'] but no description explaining what each state means or when to use each. LLMs will guess.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint metadata. addPet is destructive but unmarked, so agents cannot auto-confirm or log with elevated caution. addPet, calculate, and findPetsByStatus are all marked READ_ONLY in the brief, but getPetById lacks this in schema.