MCP server for Smogon VGC 2026 competitive Pokemon stats
The server has 14 tools with partial schema definitions visible in the tool registration files. Tool descriptions are present and moderately detailed (averaging 60-90 chars), exceeding the 20-char minimum but falling short of the production baseline of 194 chars. Parameter schemas are declared with types and descriptions for most tools, but output schemas are not documented in the source code provided. The logging wrapper adds value but does not compensate for missing output documentation. Most tools follow the verb_noun naming convention correctly (list_, get_, calculate_, analyze_, optimize_, suggest_). However, critical gaps remain: no per-tool error handling guidance visible, no idempotency hints or destructive operation safeguards for the admin_rebuild_cache tool, and incomplete parameter constraint documentation (e.g., the 'format' parameter accepts format codes like 'regf' and 'regg' but no enum or validation logic is shown in the source).
Rebuild internal cache of Pokemon data
Analyze a team composition for type coverage and weaknesses
Calculate Pokemon stats for Champions format using SP (Skill Points) system
Calculate damage between two Pokemon given their sets and conditions
Calculate Pokemon stats given base stats, EVs, IVs, and nature
Get Pokemon usage statistics for Champions format
Get common movesets for a Pokemon in a format
Get base stats for a Pokemon
No output schemas documented. While input parameters are declared with types and descriptions, the structure of return values is not specified in the source code. LLMs cannot plan downstream tool chains or parse results without knowing what fields to expect.
Parameter enums not declared in schema. The 'format' parameter across multiple tools (get_pokemon_usage, get_rankings, suggest_team_building, get_pokemon_moveset) accepts format codes like 'regf' and 'regg', but these valid values are not captured as enum constraints in the input schema. This forces LLMs to hallucinate valid values or require explicit instruction.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Get Pokemon usage statistics for a specific format
Get Pokemon rankings for a specific format
Analyze a Smogon replay for team composition and strategy
List available VGC formats supported by the server
Find optimal EV spread for a Pokemon based on goals
Get team building suggestions for VGC competitive play
Missing error handling and recovery guidance. No tool provides actionable error messages or guidance on what an LLM should do if a lookup fails (e.g., 'Pokemon not found' or 'Format not supported'). Error responses should include available alternatives and retry strategies.
Destructive/write operation (admin_rebuild_cache) lacks safeguards. The tool description is minimal ('Rebuild internal cache of Pokemon data') with no mention of side effects, confirmation step, or retry implications. A dry-run or confirmation pattern should protect against accidental cache rebuilds.
Incomplete parameter descriptions. Several parameters lack format or constraint details. For example, 'evs' and 'nature' parameters in calculate_stats are documented minimally; the description should specify the expected EV spread format (e.g., '252/0/0/252/0/0' or object structure) and valid nature names.
No pagination or result-limiting documented. Tools like get_pokemon_usage, get_rankings, and get_replay_analysis do not declare whether they return paginated results, a limit parameter, or a maximum result count. Large result sets risk context window exhaustion.
Tool names could better disambiguate overlapping functionality. 'calculate_stats' and 'calculate_damage' are clear, but 'get_pokemon_usage' vs 'get_champions_usage' and 'get_pokemon_stats' vs 'calculate_champions_stats' risk confusion. Consider renaming to 'get_pokemon_usage_regf' or adding format specificity to the description.