getcompetitive

Overview Schema Source Related Servers Discussions Admin

Resolve type effectiveness

get_type_matchup

Read-onlyIdempotent

Resolve Pokémon type effectiveness: get a damage multiplier for attacking type vs defending type/species, view offensive coverage, defensive weaknesses, or the full 18x18 chart.

Instructions

Resolve type effectiveness in the mode the arguments imply: attacker + defender returns the single multiplier (the defender may be a type or a species, whose current-generation typing is used); attacker alone returns that type's offensive coverage against all 18 types; defender alone returns everything the defender takes, including 4x weaknesses and immunities; neither returns the complete 18x18 matrix. Use get_type for a type's own defensive entry, and analyze_team when the question spans a whole team. Names are case-insensitive; an unknown type or species returns an isError. Read-only and offline.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`attacker`	No	Attacking type name; omit to read the chart from the defender's side or to get the full matrix.
`defender`	No	Defending type or species name; a species contributes its current-generation types.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	Present only alongside `chart`, spelling out how to read the full matrix (rows are attackers, columns are defenders) and the multiplier scale.
`chart`	No	Present only when neither argument was given: the full type chart as `chart[attackingType][defendingType] = multiplier`, each inner map keyed by the 18 defending type names with values 0, 0.25, 0.5, 1, 2, or 4.
`label`	No	`effectiveness` in words, e.g. "2x super effective", "neutral", "immune"; present only when both attacker and defender were given.
`attacker`	No	The attacker as supplied, echoed back; absent when no attacker argument was given.
`coverage`	No	Present only when an attacker was given without a defender: how that attacking type lands against each of the 18 defending types, keyed by defending type name ("Bug", "Dark", "Dragon", "Electric", "Fairy", "Fighting", "Fire", "Flying", "Ghost", "Grass", "Ground", "Ice", "Normal", "Poison", "Psychic", "Rock", "Steel", "Water").
`defender`	No	Resolved defender name — the type or species the multipliers were computed against; present in the matchup and defender-only replies.
`damageTaken`	No	Present only when a defender was given without an attacker: everything the defender takes, keyed by attacking type name. Combined typing is folded in, so 4x and 0.25x entries appear for dual types and 0 marks immunities.
`defenderTypes`	No	The defending typing the multiplier was computed from, e.g. ["Dragon", "Ground"] for Garchomp or ["Steel"] for a type; present in the matchup and defender-only replies.
`effectiveness`	No	Single multiplier for attacker against defender (0, 0.25, 0.5, 1, 2, or 4); present only when both attacker and defender were given.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field 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"
-}

Addedv2.0.0Sep 17, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations: it states that species names resolve to current-generation typing, that unknown names return an isError, that names are case-insensitive, and that the tool is offline. It does not detail the exact output shape, but the output schema exists and covers that.

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 a single dense paragraph that front-loads the core purpose, then enumerates the four modes in order of complexity, and ends with the sibling routing and error behavior. Every sentence earns its place; there is no filler or repetition of schema content.

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?

For a read-only, offline tool with an output schema and 100% parameter coverage, the description covers all the decision-relevant context: the four invocation modes, the species-to-typing resolution, case-insensitivity, error behavior, and the sibling tools to use instead. Nothing an agent needs to select and invoke the tool correctly is missing.

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 meaning beyond the schema by explaining how the two parameters interact: attacker alone returns offensive coverage, defender alone returns defensive coverage, and neither returns the full matrix. It also clarifies that defender accepts a species name and resolves its current-generation typing, which is not in 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 opens with a specific verb and resource ('Resolve type effectiveness') and immediately distinguishes the tool from siblings by enumerating the four argument modes (attacker+defender, attacker alone, defender alone, neither). It also names the sibling tools get_type and analyze_team, making the differentiation explicit.

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?

The description explicitly states when to use this tool versus alternatives: 'Use `get_type` for a type's own defensive entry, and `analyze_team` when the question spans a whole team.' It also clarifies the mode selection rule ('in the mode the arguments imply'), so an agent knows exactly which call shape to choose.

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