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
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Tool Definition Quality
Average 4.5/5 across 7 of 7 tools scored.
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.
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.
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.
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.
| 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. 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. 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint. Description adds behavioral details: AND logic for filters, strict token matching on name, and the requirement of a category filter when using query. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with main purpose. Every sentence adds essential information—returns, constraints, logic. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters, output schema exists, and no required params, the description covers all critical aspects: purpose, return value, filter logic, constraints, and connection to sibling tools. Fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all 7 parameters. Description adds overall semantics like combined AND logic, strict token matching, and the interaction between query and category filters, providing value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool filters Pokémon by multiple criteria (generation, type, pokedex, egg group) and returns names and Pokédex numbers. It distinguishes from sibling tools like pokeapi_get_pokemon by indicating its output is 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (to list/filter Pokémon) and provides crucial usage rules: filters use AND logic, query requires at least one categorical filter, otherwise returns empty. This guides the agent to avoid misuse.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent behavior. The description adds value by specifying the exact response structure (effect text, generation, Pokémon list), which is not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first covers purpose and output; the second provides a useful cross-reference. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, full annotations, and an existing output schema, the description sufficiently covers input, output, and usage context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema provides full parameter meaning. The description reinforces 'by name or numeric ID' but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting ability details by name or numeric ID. It enumerates the returned fields (effect text, generation, Pokémon list) and distinguishes itself from the sibling pokeapi_get_pokemon by noting that ability names come from that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a workflow where ability names are obtained from pokeapi_get_pokemon first, then details are fetched with this tool. However, it does not explicitly state when to use this tool versus alternatives, though sibling tools cover different resources.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds concrete details about returned data (e.g., effect text, sprite URL, held-by info), providing useful context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loaded with action and parameter type, then lists output details efficiently. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple single-parameter tool with output schema present, the description covers all necessary context: how to pass the identifier and what data to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes the 'identifier' parameter (100% coverage), so description adds minimal extra meaning; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'item details', and lists key fields (effect text, category, cost, etc.), clearly distinguishing it from sibling tools for other Pokémon entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for item lookups by name/ID, and sibling tools cover different entities, but no explicit when-not or alternative guidance is provided.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds behavioral context about include_learners defaulting to false due to potentially large list. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no wasted words. Front-loads key information and ends with cross-reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations, output schema, and only 2 parameters, description is complete. Covers purpose, parameters, and cross-reference. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds meaning beyond schema: identifier format 'lowercase hyphenated form', numeric ID as string, and why include_learners defaults to false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get move details' with resource 'move' and enumerates returned fields (type, damage class, etc.). It distinguishes from sibling tools by noting move 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly states when to use (to get move details) and provides cross-reference for obtaining move names. It does not explicitly list when not to use, but context is sufficient.
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%.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent. The description adds behavioral specifics: stat modifications of ±10% and preferred/disliked flavors. It also explains the listing behavior. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with clear purpose: purpose and return data, parameter usage, and motivating context (competitive team-building). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A low-complexity tool with one optional parameter, fully covered by schema. The description adds what the output contains (stats, flavors) and why it matters (competitive). An output schema exists, so response format is covered. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the parameter (name/id string, omit for all). The description adds example values ('modest', 'jolly') and re-emphasizes omission behavior, but schema coverage is 100% so baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get nature details' and specifies exactly what is returned (stat boosted/reduced, berry flavors). It differentiates from sibling tools which target other Pokémon resources (pokemon, ability, etc.). Also notes that omitting identifier lists all 25 natures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use (competitive team-building) and how to use (omit identifier for all or specify name). It doesn't explicitly exclude cases, but siblings are distinct resources so no confusion.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds useful behavioral details: include_moves is large (100-200+ moves) so defaults to false, game_version fallback behavior. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph around 100 words, front-loaded with main purpose, then parameter details. Every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (many fields returned) and existence of output schema, description explains output in detail. Covers optional behaviors, fallback, and sibling tool reference. Complete for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. Description adds extra meaning: identifier format with examples, game_version fallback explanation, include_moves size rationale. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a fully denormalized Pokémon dossier with specific fields like stats, types, abilities, evolution chain, etc. Distinguishes from sibling tool pokeapi_find_pokemon, which is for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using pokeapi_find_pokemon for discovery before calling this tool. Explains when to set include_moves=true and how game_version falls back. Provides clear context for parameter 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.
| 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
| 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 for each non-neutral attacking type (0, 0.25, 0.5, 1, 2, 4). Types absent from this map deal 1× damage. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds that defensive multipliers are correctly composed for dual-type Pokémon (e.g., Fire/Flying vs Rock = 4×), which is a notable behavioral detail beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with core purpose, then inputs and a behavioral note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are not required in description. The description covers the essential input constraints, behavior (dual-type composition), and tool's purpose. Complete for a tool with rich annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds critical context: 'Exactly one of type or pokemon must be provided' and clarifies format (lowercase for type, name or dex number for pokemon). This adds meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get' and resource 'full offensive and defensive type effectiveness breakdown'. It clearly states the tool's purpose and distinguishes it from sibling tools like pokeapi_find_pokemon or pokeapi_get_pokemon by focusing on type matchups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use: when needing type effectiveness. It specifies input options (type name or Pokémon identifier) and the constraint that exactly one must be provided. It does not explicitly state when not to use or name alternatives, but context implies it.
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!