Loading ToolBench
MCP server that provides tools to search for Pokémon and retrieve their abilities using the PokéAPI
Two tools with minimal documentation. Both have verb-noun naming (search_pokemon, get_pokemon_abilities) which is correct. However, descriptions are extremely brief (18-24 chars, well below the 50-200 char baseline for A+ tools). Input schemas are present but trivial (single string param with minimal description). No output schema documentation. No error handling guidance. No parameter constraints or validation hints. Tool descriptions do not explain WHEN to use each tool or what distinguishes them, both operate on pokemon data and could easily be confused by an LLM.
Get the abilities of a pokemon
Search for a pokemon by name
Descriptions are critically short (18-24 chars). Baseline for A+ tools is 50-200 chars. LLMs cannot determine when to select search_pokemon vs get_pokemon_abilities without richer context.
No output schema documented. LLMs cannot plan downstream calls or extract relevant fields from the Pokémon API response. Returns dict | None but structure is opaque.
Parameter descriptions are minimal ('The name of the pokemon'). No format hints, constraints, or examples. LLMs cannot validate input or understand edge cases (e.g., case sensitivity, partial matches).
Error handling is silent (returns None on exception). No guidance to LLM on what to do if a pokemon is not found or the API is unreachable. Exception is printed but not returned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
No distinction between tools. Both accept a single 'name' parameter and query the Pokémon API. Descriptions do not clarify: search_pokemon queries /pokemon/{name}, get_pokemon_abilities queries /ability/{name}. LLM may conflate them.