Loading ToolBench

Reading the current corpus…

gen-ai-starter MCP server · C · ToolBench

gen-ai-starter

A generative AI starter project with multiple example implementations including agentic chat, document processing, RAG systems, and MCP server integration. Contains a Pokemon MCP server built from OpenAPI specification.

<=2025-11-25STDIO5 tools

64/100

Definition Quality73

Protocol Readiness42

SupportabilityNot measured-

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

This is a Pokémon data lookup MCP server with 5 well-structured tools. The tools have clear, descriptive names following verb_noun convention (getPokemon, getPokemonSpecies, getType, getAbility, getMove). All tools have documented schemas with proper parameter types and descriptions. However, there are significant gaps: (1) Output schemas are not explicitly documented in the source provided, descriptions mention TOON format returns but no structured schema is visible for responses. (2) Error handling guidance is minimal, no recovery hints or categorization. (3) No evidence of pagination support despite potential for large result sets. (4) Parameter descriptions are minimal (single line). The server demonstrates competent tool design for a read-only API wrapper but lacks production-grade polish in error guidance and response documentation.

Tools (5)

getAbilityread onlysource verified73/100

Get ability information by ID or name. Returns TOON format data: id, name, is_main_series, effect, flavor_text, and list of Pokémon with that ability.

getMoveread onlysource verified73/100

Get move information by ID or name. Returns TOON format data: id, name, power, accuracy, priority, type, category, pp, effect, and effect chance.

getPokemonread onlysource verified73/100

Get a specific Pokémon by ID or name. Returns summarized data in TOON format (Token-Oriented Object Notation) for token efficiency: id, name, height, weight, types, base stats, abilities, and moves.

getPokemonSpeciesread onlysource verified73/100

Get Pokémon species information by ID or name. Returns summarized data in TOON format: id, name, color, habitat, generation, evolution chain URL, and English description.

getTyperead onlysource verified73/100

Get Pokémon type information by ID or name. Returns TOON format data: id, name, and damage relations (double damage from/to, half damage from/to, no damage from/to).

Issues (5)

HIGHtool-schema-documentation ↗

Output schemas not documented. Tools reference TOON format and specific return fields (id, name, height, weight, types, base_stats, abilities, moves) in descriptions, but no formal JSON Schema is visible for responses. LLMs cannot plan downstream operations or validate response structure without documented schemas.

getPokemongetPokemonSpeciesgetTypegetAbilitygetMove

HIGHrecovery-guide ↗

Error handling lacks recovery guidance. No indication of what error codes the tools can return, whether errors are retryable, or what the LLM should do next. E.g., if getPokemon(idOrName='invalid') fails, should the LLM retry with a search? No guidance provided.

getPokemongetPokemonSpeciesgetTypegetAbilitygetMove

MEDIUMtool-description ↗

Parameter descriptions are minimal (single line). Rubric baseline for param annotations is 72 chars average; these are ~40-50 chars. E.g., getAbility's 'idOrName' is 'The ID or name of the ability', missing context on format, examples of valid input, or what happens if input is ambiguous.

Recommendations

Document explicit JSON Schema for all tool outputs. Include example responses. For getPokemon, return schema should formalize: {id: number, name: string, height: number, weight: number, types: [{name: string, slot: number}], stats: [{stat: string, base_stat: number}], abilities: [{name: string, is_hidden: boolean}], moves: [{name: string}]}
Expand parameter descriptions to 100-150 chars per the rubric. Include: valid input formats (numeric ID vs string name), behavior when input is ambiguous (e.g., 'bulbasaur' matches multiple species), and constraints. E.g., 'The Pokémon ID (1-1025) or name (e.g., pikachu). If ambiguous, returns the primary form.'
Add error handling guidance. Document expected errors: 'HTTP 404 if Pokémon not found. Try searching with a partial name using getPokemon(partial_name=true) or list_pokemon_by_type(type).' Categorize: user-fixable (typo in name) vs retryable (temporary API outage) vs fatal.
Implement pagination for tools that return collections. Add optional limit (default 20, max 100) and offset parameters to getPokemon (for moves) and getAbility (for Pokémon list). Document in tool descriptions.
Clarify transport. The Dockerfile references streamable-http startup, but src/index.ts exports StdioServerTransport by default. Ensure HTTP is the primary mode and update package.json scripts to reflect this. Document supported transports in README.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

64/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	64	<=2025-11-25	v2