Loading ToolBench
Multi-agent AI zoo tour guide integrating local MCP server data with Wikipedia knowledge
This server has significant definition quality gaps. Four of five tools are read-only zoo database queries with adequate naming but weak descriptions that lack context about when to use them vs alternatives. The fifth tool (add_prompt_to_state) has a confusing purpose, it appears to be state management for an external LLM agent framework (Google ADK ToolContext) rather than zoo data access, creating composition confusion. Input schemas are present and properly formatted, but descriptions are generic and fall short of the 50-200 char LLM-optimized range. No output schemas are documented. Error handling is absent, no recovery guidance, no validation error messaging, no actionable feedback for the LLM. The tool composition violates the single-responsibility principle: a state management tool should not be mixed with data access tools. Overall, this reads like an early-stage prototype rather than a production-ready MCP server.
Saves the user's initial prompt to the state.
Get all animals in the zoo database
Get all animals at a specific location in the zoo
Get all animals of a specific species from the zoo database
Search for animals by name
Output schemas not documented. LLMs cannot plan downstream calls or extract structured data without knowing what fields to expect. All five tools lack documented return types, violating pattern:tool and pattern:response-shaper.
Weak tool descriptions. 'Get all animals of a specific species from the zoo database' (58 chars) lacks actionable context. LLMs cannot distinguish when to use get_animals_by_species vs get_animals_by_location vs search_animals. Descriptions should be 50-200 chars and answer WHAT, WHEN, and WHAT IT RETURNS.
get_all_animals has a bare description (20 chars): 'Get all animals in the zoo database.' This violates the 50-200 char guidance and provides no signal for tool selection. Why would an LLM call this vs search_animals? No answer.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
add_prompt_to_state is a state management tool for an external LLM framework (Google ADK ToolContext), not a zoo data access tool. It violates composition, mixing different concerns in one server. This tool should either be removed or moved to a separate agent framework MCP server.
add_prompt_to_state has confusing naming. 'add_prompt_to_state' does not follow verb_noun conventions clearly, what is 'state'? The description 'Saves the user's initial prompt to the state' references an opaque ToolContext object, not zoo data. This violates pattern:tool naming clarity.
No error handling or recovery guidance. If a species or location does not exist, the tools return empty lists without feedback. If an LLM passes an invalid parameter, no actionable error message tells the LLM what to try next. Violates pattern:recovery-guide.
No result limits or pagination declared. get_all_animals could return thousands of animals, bloating the context window. Tools should cap results (e.g., 20-50) and provide pagination (offset, limit, next_cursor). Violates pattern:paginated-result and mxe:enforce-result-limits.
Input parameter descriptions are minimal. 'The species name (e.g., 'Lion', 'Elephant', 'Giraffe')' includes example values, which LLMs tend to reuse literally rather than adapt. Use enums or constraints instead. Violates pattern:tool-description.
add_prompt_to_state parameter 'tool_context' has type 'object' with no schema details. LLMs cannot validate or construct ToolContext. This parameter should be removed (context should be server-side) or properly documented with a schema.