poke-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_pokemonA | Look up a Pokemon by name. Supports exact, partial, and misspelled names. Returns types, abilities, base stats, and other pokedex info. If the name is ambiguous, a list of candidate names is returned. |
| predict_battleA | Predict the winner of a battle between two Pokemon using a deterministic model based on base stats and type effectiveness. Same inputs always produce the same result. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools serve clearly distinct purposes: one retrieves Pokemon information, the other predicts battle outcomes. There is no overlap or ambiguity in their intended use.
Both tool names follow a consistent verb_noun pattern (get_pokemon, predict_battle), making the naming predictable and easy to reason about.
With only 2 tools, the server feels thin for a 'Pokemon' domain, but the tools are focused and each serves a distinct purpose, making it borderline acceptable for a narrow scope.
The server lacks common operations such as listing all Pokemon, retrieving moves, or detailed type charts. The stated domain implies a broader surface, leaving significant gaps that agents may need to work around.