Skip to main content
Glama

List regulation sets

list_regulations
Read-onlyIdempotent

Retrieve all Pokémon Champions/VGC regulation sets with dates, status, and roster sizes, and identify the current active set. Get an offline summary of each set's key details.

Instructions

List every Pokémon Champions / VGC Regulation Set with its id, dates, status, and roster size. Takes no arguments; status is relative to today and the active set is also returned as currentSet (null when none is). Use get_regulation for one set's full rules and roster, check_legality to validate a team. Read-only and offline over the bundled regulation data — no network, auth, or rate limits; returns game, currentSet, and one summary per set (id, name, status, start, end, eligibleCount, megaCount, notes).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
gameYesGame every listed set belongs to ("Pokémon Champions").
noteYesStanding note on how Regulation Sets work: the roster is seasonal and eligibility is by base species, so every form of a listed species is legal.
setsYesOne summary per bundled Regulation Set, in chronological order (M-A through M-C).
currentSetYesId of the one set whose status is "current" today, or null when no set is active.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "currentSet": {
      +      "description": "Id of the one set whose status is \"current\" today, or null when no set is active.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "game": {
      +      "description": "Game every listed set belongs to (\"Pokémon Champions\").",
      +      "type": "string"
      +    },
      +    "note": {
      +      "description": "Standing note on how Regulation Sets work: the roster is seasonal and eligibility is by base species, so every form of a listed species is legal.",
      +      "type": "string"
      +    },
      +    "sets": {
      +      "description": "One summary per bundled Regulation Set, in chronological order (M-A through M-C).",
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "eligibleCount": {
      +            "description": "How many base species are on the legal roster.",
      +            "type": "number"
      +          },
      +          "end": {
      +            "description": "Last day the set is in force, ISO 8601 (inclusive).",
      +            "type": "string"
      +          },
      +          "game": {
      +            "description": "Game the set belongs to (\"Pokémon Champions\").",
      +            "type": "string"
      +          },
      +          "id": {
      +            "description": "Regulation id, e.g. \"m-a\", \"m-b\", \"m-c\".",
      +            "type": "string"
      +          },
      +          "megaCount": {
      +            "description": "How many base species on the roster may Mega Evolve.",
      +            "type": "number"
      +          },
      +          "name": {
      +            "description": "Display name, e.g. \"Regulation Set M-C\".",
      +            "type": "string"
      +          },
      +          "notes": {
      +            "description": "Curator summary of the format and what it changed over the previous set.",
      +            "type": "string"
      +          },
      +          "start": {
      +            "description": "First day the set is in force, ISO 8601 (inclusive).",
      +            "type": "string"
      +          },
      +          "status": {
      +            "description": "Status relative to today: \"past\", \"current\", or \"upcoming\".",
      +            "enum": [
      +              "past",
      +              "current",
      +              "upcoming"
      +            ],
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "id",
      +          "name",
      +          "game",
      +          "status",
      +          "start",
      +          "end",
      +          "eligibleCount",
      +          "megaCount",
      +          "notes"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "game",
      +    "currentSet",
      +    "sets",
      +    "note"
      +  ],
      +  "type": "object"
      +}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Even though annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, the description adds meaningful behavioral detail: status is relative to today, `currentSet` is null when none exists, and the tool is offline over bundled data with no network, auth, or rate limits. This goes well beyond what annotations provide and shapes caller expectations.

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 tightly written sentences: purpose, no-args/status behavior, then alternatives and safety/offline guarantees. Every clause earns its place; no filler or repetition of schema fields.

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?

The description covers the tool's scope, output summary fields, status timing, currentSet semantics, offline/no-auth behavior, and routes to sibling tools for related needs. The output schema covers detailed return structure, so nothing essential is missing for correct invocation.

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?

With zero parameters, the input schema is already exhaustive. The description reinforces this by stating 'Takes no arguments,' which is a small but useful confirmation for an agent deciding whether any optional inputs exist. Baseline 4 applies because there are no parameter semantics to elaborate.

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 'List every Pokémon Champions / VGC Regulation Set' — a specific verb and resource with the exact fields returned (id, dates, status, roster size). It also distinguishes itself from `get_regulation` and `check_legality`, so an agent can identify this as the list/summary tool without opening other definitions.

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 alternatives: 'Use `get_regulation` for one set's full rules and roster, `check_legality` to validate a team.' It also tells the agent that the tool takes no arguments, making the call context unambiguous.

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