A
license-
qualityC
maintenanceEnables querying Pokémon data from PokéAPI, including listing Pokémon, fetching details by name or ID, and getting type matchups.
25
ISC
pokeapi-mcp-server
Server Details
Look up Pokémon, moves, abilities, items, natures, and type matchups from PokéAPI v2.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/pokeapi-mcp-server
- GitHub Stars
- 1
- Server Listing
- @cyanheads/pokeapi-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.5/5.0
Tool DescriptionsA
Average 4.5/5 across 7 of 7 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct aspect of Pokémon data: searching, fetching Pokémon details, abilities, items, moves, natures, and type matchups. No functional overlap exists.
Naming Consistency5/5
All tools follow the 'pokeapi_verb_noun' pattern with consistent use of 'find_' for search and 'get_' for retrieval, making the API predictable and easy to understand.
Tool Count5/5
With 7 tools, the server covers the core interactions needed for Pokémon data without being overwhelming. Each tool serves a clear purpose and adds significant value.
Completeness4/5
The tool set covers essential operations: search, detailed Pokémon dossier, abilities, items, moves, natures, and type matchups. Minor gaps exist (e.g., no independent move/ability listing or move search), but the integrated data in get_pokemon and find_pokemon mitigates most needs.
Available Tools
7 toolspokeapi_find_pokemonFind PokémonARead-onlyIdempotentInspect
Filter Pokémon by generation, type, regional pokédex, or egg group. Returns names and Pokédex numbers suitable for follow-up pokeapi_get_pokemon calls. All filters are optional and combined with AND logic; query adds strict token matching on name. When no category filter is provided alongside query, returns an empty result — at least one categorical filter is required.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type name (e.g. "fire", "psychic"). Filters to Pokémon of this type. | |
| limit | No | Maximum results to return. Positive integer; defaults to 50. | |
| query | No | Strict token match on name. "chu" matches "pikachu" and "raichu". Case-insensitive. | |
| offset | No | Offset into the filtered result set for pagination. Non-negative integer; defaults to 0. | |
| pokedex | No | Regional pokédex name (e.g. "kanto", "hoenn", "galar"). Filters to entries in that dex. | |
| egg_group | No | Egg group name (e.g. "monster", "fairy", "dragon"). Filters to Pokémon in this egg group. | |
| generation | No | Generation name (e.g. "generation-i", "generation-iii"). Filters to Pokémon introduced in this generation. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| shown | Yes | Number of results in this response. |
| notice | No | Guidance when no Pokémon matched the filters. |
| pokemon | Yes | Matching Pokémon entries. |
| totalCount | Yes | Total matching Pokémon before limit/offset. |
Tool Definition Quality
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly=true and idempotent=true; the description adds that filters combine with AND, query does strict token matching, and returns empty result if no categorical filter with query. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and filtering criteria, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional params and output schema, description covers filtering behavior, edge case, and return type. Pagination not explained but schema suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: explains query token matching (case-insensitive, substring), AND logic, and the requirement of at least one categorical filter when query is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Filter Pokémon by generation, type, regional pokédex, or egg group', clearly stating the verb (Filter) and resource (Pokémon). It distinguishes from siblings like 'pokeapi_get_pokemon' by noting it returns names and Pokédex numbers suitable for follow-up calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (all filters optional, AND logic) and when not (at least one categorical filter required alongside query). It implies the follow-up use case but does not directly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pokeapi_get_abilityGet AbilityARead-onlyIdempotentInspect
Get ability details by name or numeric ID — full English effect text, short effect text, generation introduced, and the list of Pokémon that have the ability (including hidden-ability flag and slot). Ability names are returned by pokeapi_get_pokemon in the abilities array.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Ability name in lowercase hyphenated form (e.g. "overgrow", "speed-boost") or numeric ID as a string. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Ability ID. |
| name | Yes | Ability name in hyphenated lowercase. |
| pokemon | Yes | Pokémon that have this ability. |
| effectText | Yes | Full English effect description. Null when unavailable. |
| generation | Yes | Generation in which the ability was introduced. |
| shortEffectText | Yes | Short English effect summary. Null when unavailable. |
Tool Definition Quality
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by detailing the returned fields and the format of the ability names, which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations (readOnlyHint, openWorldHint, idempotentHint) and the existence of an output schema, the description is complete about what the tool returns and its safe, idempotent nature. It lacks explicit error handling info, but this is mitigated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, with a clear description of its format (lowercase hyphenated or numeric ID). The description adds the extra context that ability names are returned by pokeapi_get_pokemon, providing useful linkage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get ability details by name or numeric ID', specifying the verb and resource. It also lists the exact information returned (full English effect text, etc.), and distinguishes from siblings by noting that ability names come from pokeapi_get_pokemon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an ability name/ID and want details, and references the sibling tool pokeapi_get_pokemon as a source of ability names. While it doesn't explicitly state when not to use it or compare alternatives, the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pokeapi_get_itemGet ItemARead-onlyIdempotentInspect
Get item details by name or numeric ID — effect text, category, in-game cost, fling power, item attributes (holdable, consumable, etc.), sprite URL, and Pokémon that commonly hold it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Item name in lowercase hyphenated form (e.g. "choice-specs", "leftovers") or numeric ID as a string. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Item ID. |
| cost | Yes | Purchase cost in Pokédollars. 0 means not sold in shops. |
| name | Yes | Item name in hyphenated lowercase. |
| category | Yes | Item category (e.g. "held-items", "medicine"). |
| spriteUrl | Yes | Item sprite URL. Null when no sprite is available. |
| attributes | Yes | Item attributes (e.g. "holdable", "consumable", "usable-in-battle"). |
| effectText | Yes | Full English effect description. Null when unavailable. |
| flingPower | Yes | Fling move base power when this item is flung. Null if not throwable. |
| heldByPokemon | Yes | Pokémon that commonly hold this item in the wild. |
| shortEffectText | Yes | Short English effect summary. Null when unavailable. |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds context by listing the specific data returned (e.g., effect text, sprite URL), going beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and lists key details. It is efficient, though slightly long due to the enumeration of fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still adds valuable context on the return fields (e.g., effect text, category). For a simple get tool with comprehensive annotations and schema, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and describes the identifier parameter adequately. The description adds no new information about the parameter beyond what the schema provides; it merely repeats the format hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get item details by name or numeric ID' and enumerates specific fields returned (effect text, category, cost, etc.). It distinguishes from sibling tools like pokeapi_get_ability and pokeapi_get_move by specifying item-specific results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need item details) but does not provide explicit guidance on when not to use it or alternatives beyond sibling names. It is clear enough for a retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pokeapi_get_moveGet MoveARead-onlyIdempotentInspect
Get move details by name or numeric ID — type, damage class, power, accuracy, PP, priority, target, stat changes, status-effect chance, and full English effect text. Set include_learners=true to include the list of Pokémon that can learn the move. Move names are available from pokeapi_get_pokemon when include_moves=true.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Move name in lowercase hyphenated form (e.g. "flamethrower", "close-combat") or numeric ID as a string. | |
| include_learners | No | Include the list of Pokémon that can learn this move. Defaults to false as the list can be large. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Move ID. |
| pp | Yes | Base PP. Null when unavailable. |
| name | Yes | Move name in hyphenated lowercase. |
| type | Yes | Elemental type (e.g. "fire"). |
| power | Yes | Base power. Null for status moves. |
| target | Yes | Target selection (e.g. "selected-pokemon", "all-opponents"). |
| accuracy | Yes | Accuracy percentage (0–100). Null for moves that always hit. |
| priority | Yes | Priority bracket (positive = higher priority, negative = lower). |
| effectText | Yes | Full English effect description. Null when unavailable. |
| damageClass | Yes | Damage class: physical, special, or status. Null when unavailable. |
| statChanges | Yes | Stat stage changes caused by this move. |
| effectChance | Yes | Secondary effect chance percentage. Null when not applicable. |
| shortEffectText | Yes | Short English effect summary. Null when unavailable. |
| learnedByPokemon | Yes | Pokémon names that can learn this move (populated when include_learners=true). |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent. The description adds behavior like the default false for include_learners and its rationale, as well as the structure of returned details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: first states purpose, second introduces optional parameter, third provides cross-reference. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema present), the description fully covers operation, parameters, and even links to sibling tool for name discovery.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description enriches the identifier parameter with format examples and explains the include_learners default and performance consideration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves move details by name or ID, listing specific fields (type, power, accuracy, etc.). It distinguishes from sibling tools like pokeapi_get_pokemon by focusing on moves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool (get move details), provides guidance on sourcing move names from another tool, and cautions about the size of the learners list, aiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pokeapi_get_natureGet NatureARead-onlyIdempotentInspect
Get nature details — the stat boosted (+10%), stat reduced (-10%), and preferred/disliked berry flavors. Omit the identifier to list all 25 natures at once. Natures are critical for competitive team-building: every non-neutral nature modifies two stats by ±10%.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | No | Nature name (e.g. "modest", "jolly") or ID 1–25 as a string. Omit to list all 25 natures. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| natures | Yes | One or all 25 natures depending on whether identifier was provided. |
| isListAll | Yes | True when all 25 natures are returned (no identifier provided). |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. Description adds that omitting parameter lists all natures and explains stat modification percentages, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Front-loaded with the tool's purpose, then usage guidance, then contextual importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one optional parameter, an output schema present, and clear sibling context, the description fully covers how and why to use the tool, including competitive relevance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains the 'identifier' parameter. The description mostly reiterates the 'omit to list all' behavior, adding minimal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'nature details', listing exactly what is returned (stat boosted/reduced, berry flavors). It clearly distinguishes from sibling tools which target different Pokemon entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: omitting identifier lists all 25 natures. No explicit when-not-to-use or alternatives, but the sibling set naturally differentiates usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pokeapi_get_pokemonGet PokémonARead-onlyIdempotentInspect
Get a fully denormalized Pokémon dossier in a single call — base stats, types, abilities (with full English effect text), height/weight, resolved evolution chain, sprite URLs including official artwork, species flavor text, variety list, capture rate, growth rate, gender rate, legendary/mythical flags, egg groups, and (optionally) a summarized learnable-move list. Accepts a name (lowercase, hyphens for spaces, e.g. "bulbasaur", "mr-mime") or Pokédex number. Set include_moves=true to include the move summary (large); defaults to false. Use game_version to select flavor text from a specific game (e.g. "sword", "red"); falls back to the most recent English entry when the version is not found. Use pokeapi_find_pokemon to discover Pokémon by type, generation, or egg group before calling this tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Pokémon name (lowercase hyphenated, e.g. "bulbasaur", "mr-mime") or Pokédex number as a string (e.g. "1", "25"). | |
| game_version | No | PokéAPI version name to filter flavor text (e.g. "sword", "red", "scarlet"). Falls back to the most recent English entry when the version is not found. | |
| include_moves | No | Include the full learnable-move summary. Defaults to false because the list is large (100–200+ moves). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | National Pokédex number. |
| name | Yes | Canonical Pokémon name in hyphenated lowercase. |
| genus | Yes | English genus (e.g. "Seed Pokémon"). Null when unavailable. |
| moves | Yes | Learnable moves (populated when include_moves=true, empty otherwise). |
| stats | Yes | Base stats. |
| types | Yes | Type names ordered by slot (e.g. ["fire", "flying"]). |
| sprites | Yes | Sprite URLs. |
| heightDm | Yes | Height in decimetres. |
| weightHg | Yes | Weight in hectograms. |
| abilities | Yes | Abilities with full effect text. |
| eggGroups | Yes | Egg group names. |
| moveCount | Yes | Total number of learnable moves regardless of include_moves. |
| varieties | Yes | All forms and variants of this species. |
| genderRate | Yes | Gender ratio: -1 genderless, 0 always male, 8 always female, 1–7 fraction (eighths) female. |
| generation | Yes | Generation introduced (e.g. "generation-i"). |
| growthRate | Yes | Growth rate name (e.g. "medium-slow"). |
| isMythical | Yes | True for mythical Pokémon. |
| captureRate | Yes | Base capture rate (0–255). |
| isLegendary | Yes | True for legendary Pokémon. |
| evolutionChain | Yes | Evolution tree rooted at the base species. |
| speciesFlavorText | Yes | Flavor text from the selected (or most recent) game version. Null when none available. |
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds specific behaviors: fallback logic for game_version to most recent English entry, default for include_moves to false because list is large, and comprehensive single-call retrieval. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, ~100 words, front-loaded with purpose. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations cover safety, the description fully explains purpose, parameters, alternative tool, and behavior. Complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. Description reinforces with formatting examples (lowercase, hyphens) and adds context for include_moves size and game_version fallback, providing slight added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get a fully denormalized Pokémon dossier in a single call' and enumerates the data fields. It distinguishes from sibling tool pokeapi_find_pokemon by recommending it for discovery before calling this one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use pokeapi_find_pokemon for discovery first, and explains when include_moves should be false due to size. Lacks explicit 'when not to use' but provides clear context for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pokeapi_get_type_matchupsGet Type MatchupsARead-onlyIdempotentInspect
Get the full offensive and defensive type effectiveness breakdown. Provide either a type name (e.g. "fire", "psychic") or a Pokémon identifier (name or dex number). For dual-type Pokémon, the defensive multipliers are correctly composed (e.g. Fire/Flying vs Rock = 4× because both types are weak to Rock). Exactly one of type or pokemon must be provided.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type name in lowercase (e.g. "fire", "water", "psychic"). Provide this or pokemon, not both. | |
| pokemon | No | Pokémon name or Pokédex number. The server resolves the types automatically. Provide this or type, not both. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| queryType | Yes | How the query was resolved: "type" for a direct type query, "pokemon" for a Pokémon lookup. |
| resolvedTypes | Yes | The type name(s) the query resolved to. |
| defensiveMatchups | Yes | Defensive matchups — composed correctly for dual-type Pokémon. |
| offensiveRelations | Yes | Offensive effectiveness (populated for single-type queries; null for dual-type Pokémon where per-type breakdown does not compose cleanly). |
| composedMultipliers | Yes | Multiplier (0, 0.25, 0.5, 1, 2, 4) for every attacking type touched by at least one of the resolved defending type(s), including net-neutral 1× entries where a dual type composes to a cancellation (e.g. Fire/Flying vs Ice: 0.5× then 2× = 1×). A type absent from this map relates to neither defending type and also deals 1× damage. |
Tool Definition Quality
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds important behavioral detail about dual-type defensive multipliers being correctly composed, and the constraint that exactly one of type or pokemon is required. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no extraneous words. Front-loaded with purpose and immediately provides usage conditions. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the straightforward tool (type matchups), full schema coverage, and presence of output schema and annotations, the description covers all needed context: purpose, input options, constraints, and a key behavioral note. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. Description adds meaning by explaining the mutual exclusivity of parameters and providing example formats ('fire', 'psychic', name or dex number). This aids agent understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the full offensive and defensive type effectiveness breakdown' with specific verb and resource. It distinguishes from siblings like pokeapi_find_pokemon and pokeapi_get_pokemon which focus on individual Pokemon data rather than type matchups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Provide either a type name... or a Pokémon identifier... Exactly one must be provided.' It gives examples and a concrete dual-type scenario. While it doesn't explicitly say when not to use, the context is clear given siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Flicense-qualityDmaintenanceProvides Pokemon information from PokeAPI including stats, types, height, and weight. Enables looking up Pokemon by name/ID, getting random Pokemon by type, and comparing Pokemon side-by-side.
- Alicense-qualityDmaintenanceEnables fetching detailed Pokémon data from PokéAPI, including Pokémon info, types, moves, abilities, and search with pagination.113Apache 2.0
- Alicense-qualityDmaintenanceEnables fetching Pokémon data from PokeAPI, searching for Pokémon and moves, and simulating battles between two Pokémon with type effectiveness and status effects.MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.