Skip to main content
Glama

Get type matchup chart entry

get_type
Read-onlyIdempotent

Get the defensive profile of a Pokémon type: its weaknesses, resistances, immunities, and Hidden Power IVs. Use for analyzing a type's own matchups.

Instructions

Get the defensive profile of one type: what it is weak to, what it resists, what it is immune to, plus the Hidden Power IVs for that type. Use it for a type's own matchups; for one specific pairing pass attacker and defender to get_type_matchup, and for a Pokémon's combined defensive chart give get_type_matchup the species name instead. Accepts type names case-insensitively; unknown types return an isError. Read-only and offline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesType name, e.g. "Steel", "Fairy", "Ground".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
genYesAlways 0 in the bundled dataset — types are not stamped with the generation they were introduced in.
nameYesType name, e.g. "Steel".
HPivsYesIVs needed to make Hidden Power come out as this type, keyed by stat id; only the stats this type pins down are listed.
immunitiesYesAttacking types this type takes 0x from, e.g. ["Poison"] for Steel; empty when it has none.
weaknessesYesAttacking types this type takes 2x from, e.g. ["Fire", "Ground"] for Steel; empty when it has none.
damageTakenYesMultiplier this type takes from each attacking type, keyed by attacking type name. Values: 0 (immune), 0.5 (resisted), 1 (neutral), 2 (weak). Keys are "Bug", "Dark", "Dragon", "Electric", "Fairy", "Fighting", "Fire", "Flying", "Ghost", "Grass", "Ground", "Ice", "Normal", "Poison", "Psychic", "Rock", "Steel", "Water"; e.g. {"Fire": 2, "Ground": 2, "Water": 0.5} for Steel.
resistancesYesAttacking types this type takes 0.5x from; empty when it has none.
isNonstandardYes"Future" when the type does not exist in the dataset (e.g. Dark in generation 1) and "Past" when it no longer exists; null for types that are standard in that generation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.2.0
    • 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"
      -}
    • changedOutput schema / properties / isNonstandard / description
      Previous value: -"\"Future\" when the type does not exist yet in the requested generation (e.g. Dark in generation 1) and \"Past\" when it no longer exists; null for types that are standard in that generation."New value: +"\"Future\" when the type does not exist in the dataset (e.g. Dark in generation 1) and \"Past\" when it no longer exists; null for types that are standard in that generation."
  2. Changed3 schema fields changedv1.1.1
    • addedInput schema / properties / generation / description
      Added value: +"Generation whose data to use, 1-9 (default 9). Earlier generations omit moves, items, abilities, and forms that did not exist yet."
    • addedInput schema / properties / type / description
      Added value: +"Type name, e.g. \"Steel\", \"Fairy\", \"Ground\"."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "HPivs": {
      +      "additionalProperties": false,
      +      "description": "IVs needed to make Hidden Power come out as this type, keyed by stat id; only the stats this type pins down are listed.",
      +      "properties": {
      +        "atk": {
      +          "description": "Required Attack IV (30 or 31); absent when this Hidden Power type does not constrain it.",
      +          "type": "number"
      +        },
      +        "def": {
      +          "description": "Required Defense IV (30 or 31); absent when this Hidden Power type does not constrain it.",
      +          "type": "number"
      +        },
      +        "hp": {
      +          "description": "Required HP IV (30 or 31); absent when this Hidden Power type does not constrain it.",
      +          "type": "number"
      +        },
      +        "spa": {
      +          "description": "Required Special Attack IV (30 or 31); absent when this Hidden Power type does not constrain it.",
      +          "type": "number"
      +        },
      +        "spd": {
      +          "description": "Required Special Defense IV (30 or 31); absent when this Hidden Power type does not constrain it.",
      +          "type": "number"
      +        },
      +        "spe": {
      +          "description": "Required Speed IV (30 or 31); absent when this Hidden Power type does not constrain it.",
      +          "type": "number"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "damageTaken": {
      +      "additionalProperties": {
      +        "type": "number"
      +      },
      +      "description": "Multiplier this type takes from each attacking type, keyed by attacking type name. Values: 0 (immune), 0.5 (resisted), 1 (neutral), 2 (weak). Keys are \"Bug\", \"Dark\", \"Dragon\", \"Electric\", \"Fairy\", \"Fighting\", \"Fire\", \"Flying\", \"Ghost\", \"Grass\", \"Ground\", \"Ice\", \"Normal\", \"Poison\", \"Psychic\", \"Rock\", \"Steel\", \"Water\"; e.g. {\"Fire\": 2, \"Ground\": 2, \"Water\": 0.5} for Steel.",
      +      "propertyNames": {
      +        "type": "string"
      +      },
      +      "type": "object"
      +    },
      +    "gen": {
      +      "description": "Always 0 in the bundled dataset — types are not stamped with the generation they were introduced in.",
      +      "type": "number"
      +    },
      +    "immunities": {
      +      "description": "Attacking types this type takes 0x from, e.g. [\"Poison\"] for Steel; empty when it has none.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "isNonstandard": {
      +      "description": "\"Future\" when the type does not exist yet in the requested generation (e.g. Dark in generation 1) and \"Past\" when it no longer exists; null for types that are standard in that generation.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "name": {
      +      "description": "Type name, e.g. \"Steel\".",
      +      "type": "string"
      +    },
      +    "resistances": {
      +      "description": "Attacking types this type takes 0.5x from; empty when it has none.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "weaknesses": {
      +      "description": "Attacking types this type takes 2x from, e.g. [\"Fire\", \"Ground\"] for Steel; empty when it has none.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "name",
      +    "gen",
      +    "isNonstandard",
      +    "damageTaken",
      +    "weaknesses",
      +    "resistances",
      +    "immunities",
      +    "HPivs"
      +  ],
      +  "type": "object"
      +}
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds practical behavioral context beyond those: input is case-insensitive, unknown types return an isError, and the operation is read-only and offline.

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, each earning their place: one states the function and outputs, one gives usage routing, and one covers input behavior and errors. The most important information is front-loaded and there is no filler.

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 required parameter, full schema coverage, annotations covering safety, and an output schema present, the description is complete. It also covers error behavior, case sensitivity, and alternative tools, leaving no practical gap for an agent deciding whether and how to invoke it.

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 for the single parameter is 100%, so the baseline is 3. The description adds value by specifying case-insensitive acceptance and the isError behavior for unknown type names, which are not present 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 states a specific verb ('Get the defensive profile') and resource ('one type'), and enumerates what it returns: weaknesses, resistances, immunities, and Hidden Power IVs. It also explicitly contrasts itself with the sibling get_type_matchup, so an agent can distinguish the two without opening schemas.

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 gives clear when-to-use guidance: use it for a type's own matchups, use get_type_matchup for a specific attacking/defending pairing, and use get_type_matchup with a species name for a Pokémon's combined defensive chart. This is explicit routing to alternatives with no ambiguity.

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