Loading ToolBench
MCP server for managing animal rescue operations, including listing animals, searching by ID or name, and processing pet adoptions
The server implements 4 well-defined tools with explicit registration, schemas, and descriptions. All tools have input schemas with type definitions and descriptions. Output schemas are documented via Zod. However, descriptions are generic and lack specificity about when/why to use each tool, parameter descriptions could be more detailed, and error handling guidance is minimal. The naming follows verb-noun conventions appropriately. Tools are single-responsibility and composable.
Adopt a pet by id, only use this if you know the id of the animal, if the output is null there was an error. If a pet is not compatible with the customer, urge them to reconsider and adopt a more compatible pet.
Get an animal by id, only use this if you know the id of the animal
List all animals in the animal rescue service
Find an animal by name, only use this if you know the name of the animal
Parameter descriptions lack specificity and constraints. The 'id' parameter in get_animal_by_id and adopt_pet has only generic description 'The ID of the animal to retrieve/adopt' with no format constraints, valid value ranges, or examples of valid ID patterns (e.g., 'dog-001', 'cat-002').
Tool descriptions lack WHEN guidance and error context. All tool descriptions are 50-80 characters and focus only on WHAT the tool does. They do not explain when to use each tool instead of alternatives (e.g., list_animals vs search_animals_by_name), or what happens on failure. The adopt_pet description mentions 'if output is null there was an error' but does not explain HOW to recover or what caused the error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Error handling does not guide LLM recovery. The adopt_pet tool returns null on error with an instruction comment ('if output is null there was an error') but the tool implementation does not document what errors are possible, whether they are retryable, or what the LLM should do next. No error classification (retryable vs user-fixable vs fatal) is present.
Output schema documentation is implicit (Zod schemas in code) rather than explicit in tool descriptions. LLMs cannot see Zod schema definitions directly, they need human-readable descriptions of what fields are returned, their types, and what they contain. E.g., list_animals returns { animals: Animal[] } but the description does not explain what fields each Animal contains or how to use them in downstream calls.
No pagination or result-limiting guidance. list_animals returns all animals in the database with no limit parameter or explanation of how many results to expect. As the dataset grows, this could bloat context windows. The description should state 'returns up to N animals' or offer limit/offset parameters.
Tool naming does not disambiguate similar operations. The description says 'Find an animal by name' but the tool is named 'search_animals_by_name'. This is clear enough, but search_animals_by_name and get_animal_by_id both retrieve a single animal, the descriptions do not explain why an LLM should choose one over the other (search returns first match by name; get requires exact ID).