getcompetitive

Overview Schema Source Related Servers Discussions Admin

Search the dataset by name

search_dex

Read-onlyIdempotent

Find species, moves, items, abilities, or natures by partial name or Showdown ID, then use the returned canonical name for a full Pokédex lookup.

Instructions

Find species, moves, items, abilities, or natures by case-insensitive substring of name or Showdown id, sorted by National Dex number and truncated to limit. Use it when the exact name is uncertain, then call the matching lookup (get_pokemon, get_move, get_item, get_ability, get_nature) with the name it returns. Exactly one kind is searched per call; and the reply echoes kind, query, and total match count. Read-only and offline; a blank query is rejected as an error instead of dumping the dataset.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No	Table to search; one per call (default "species").	species
`limit`	No	Maximum results returned, 1-100 (default 20).
`query`	Yes	Substring to match against name and Showdown id, e.g. "oger", "sword".

Output Schema

TableJSON Schema

Name	Required	Description
`kind`	Yes	The table that was searched, echoed back from the `kind` argument.
`count`	Yes	Total number of matches the query found, before truncation to `limit` — compare against `results.length` to see whether the list was cut short.
`query`	Yes	The query exactly as it was supplied (not lower-cased or trimmed).
`results`	Yes	Matching entries sorted by `num` ascending and truncated to `limit`; empty when nothing matched.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.2.0Sep 18, 2026

removedInput schema / properties / generation

Removed value: -{
-  "default": 9,
-  "description": "Generation whose data to use, 1-9 (default 9). Earlier generations omit moves, items, abilities, and forms that did not exist yet.",
-  "maximum": 9,
-  "minimum": 1,
-  "type": "integer"
-}

removedOutput schema / properties / results / items / properties / tier

Removed value: -{
-  "description": "Competitive tier — present only when `kind` is \"species\"; absent for moves, items, abilities, and natures.",
-  "type": "string"
-}

Addedv2.0.0Sep 17, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context: case-insensitive matching, sorting by National Dex number, truncation to limit, the echoed response fields (kind, query, total match count), offline operation, and blank-query rejection. Nothing contradicts the 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 sentences with no wasted words: the first states the core function, the second gives usage and routing, the third covers constraints and response behavior. It is front-loaded with the main purpose and every sentence earns its place.

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 and annotations cover the safety profile, the description covers all agent-relevant details: what is searched, how matches are ordered and truncated, the one-kind constraint, blank-query error, and the follow-up lookup workflow. Nothing essential is missing for correct invocation and interpretation.

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 description coverage is 100%, so the baseline is 3. The description adds value by clarifying the query semantics (case-insensitive substring over name or Showdown id), reinforcing that exactly one kind is searched per call, and explaining that limit truncates the sorted result. This is above baseline but not a full replacement for the schema's explicit enum and range details.

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 ('Find'), names the exact resources (species, moves, items, abilities, or natures), and states the matching method (case-insensitive substring of name or Showdown id) plus ordering and truncation. It also distinguishes itself from the lookup siblings by explicitly directing the agent to call get_pokemon, get_move, etc., afterward. This leaves no ambiguity about what the tool does.

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 explicitly says when to use it ('Use it when the exact name is uncertain') and names the exact alternative lookups (get_pokemon, get_move, get_item, get_ability, get_nature) that should be called with the returned name. It also states the one-kind-per-call restriction and the blank-query error behavior. This is strong routing guidance with no inference required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.