Skip to main content
Glama
mriver15

getcompetitive

by mriver15
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Analyze Meta

analyze_meta
Read-onlyIdempotent

Analyze Pokémon Champions meta from measured tournament data: usage-ranked threats, two-window usage shifts, and standard sets.

Instructions

Pokémon Champions meta intelligence, dispatching on mode: "threats" for the usage-ranked threat list, "compare" for the two-window usage deltas and emerging cores, "set" for one species’ most-played standard set (batched). Each mode carries the same documented fields the dedicated tools had. Read-only and offline; usage-derived from measured tournament data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYesWhich operation to run: "threats", "compare", "set".
detailNoHow much detail to return: "compact" (default) gives conclusions and the numbers needed to reason; "evidence" adds ranges, benchmarks and per-row detail; "debug" adds provenance and every intermediate. Ask for more only when the reasoning actually needs it — model context is the expensive resource.
speciesNoBase species or form name, e.g. "Garchomp", "Indeedee-F" (case- and punctuation-insensitive). Pass an array to fetch several sets in one call, which returns `sets` instead of the flat set.
regulationNo
includeRecordedNoAlso read the local, per-user record of sets the reasoning generated (`record_set`) and return the ones filed under the requested species as `recorded`. They carry no rank, usage share or sample, so they are never merged into the usage-derived fields; a record that named no regulation matches any `regulation` scope. Absent or false, the answer is the measured meta only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv8.0.2
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "How much detail to return: \"compact\" (default) gives conclusions and the numbers needed to reason; \"evidence\" adds ranges, benchmarks and per-row detail; \"debug\" adds provenance and every intermediate. Ask for more only when the reasoning actually needs it — model context is the expensive resource.",
+  "enum": [
+    "compact",
+    "evidence",
+    "debug"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / includeRecorded
      Added value: +{
+  "description": "Also read the local, per-user record of sets the reasoning generated (`record_set`) and return the ones filed under the requested species as `recorded`. They carry no rank, usage share or sample, so they are never merged into the usage-derived fields; a record that named no regulation matches any `regulation` scope. Absent or false, the answer is the measured meta only.",
+  "type": "boolean"
+}
    • addedInput schema / properties / mode
      Added value: +{
+  "description": "Which operation to run: \"threats\", \"compare\", \"set\".",
+  "enum": [
+    "threats",
+    "compare",
+    "set"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / regulation
      Added value: +{
+  "anyOf": [
+    {
+      "description": "Optional regulation set id, e.g. \"m-c\" (matched case- and punctuation-insensitively); omit to list every regulation with its threat count.",
+      "type": "string"
+    },
+    {
+      "description": "Regulation id, e.g. \"m-c\" (case- and punctuation-insensitive); omitted, the single regulation with history is used.",
+      "type": "string"
+    },
+    {
+      "description": "Optional regulation set id, e.g. \"m-c\"; omit to search every list.",
+      "type": "string"
+    }
+  ]
+}
    • addedInput schema / properties / species
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "maxItems": 24,
+      "minItems": 1,
+      "type": "array"
+    }
+  ],
+  "description": "Base species or form name, e.g. \"Garchomp\", \"Indeedee-F\" (case- and punctuation-insensitive). Pass an array to fetch several sets in one call, which returns `sets` instead of the flat set."
+}
    • addedInput schema / required
      Added value: +[
+  "mode"
+]
  2. Addedv6.2.2

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already carry readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only and offline' and 'usage-derived from measured tournament data', adding a useful data-source and side-effect guarantee. It also notes batched set retrieval. No contradiction with 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 filler: core purpose is front-loaded, the mode breakdown is compact, and the read-only/offline caveat is placed at the end. Every sentence contributes either selection guidance or behavioral context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema covers the mechanical details of all five parameters, and the description covers the conceptual operation switching, so an agent can select and invoke the main modes correctly. The main gap is the reference to 'the same documented fields the dedicated tools had' without naming or describing those fields, which may leave return-value expectations underspecified.

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?

The description adds real meaning to the `mode` parameter beyond the schema enum by explaining what each mode returns: threat lists, usage deltas/emerging cores, and standard sets. The remaining parameters are already well documented in the schema, so the 80% coverage baseline is comfortably met.

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 names a specific resource (Pokémon Champions meta intelligence) and a concrete dispatch mechanism on `mode`, with each mode given a distinct outcome: usage-ranked threat list, two-window usage deltas/cores, and most-played standard set. The meta-focused wording separates it from sibling team/battle tools, even without naming them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The mode descriptions imply when each operation is useful, and the phrase 'dedicated tools' hints at consolidation, but there is no explicit when-to-use versus alternatives such as analyze_team or analyze_battle, nor any stated exclusions. The agent has to infer the routing based on the word 'meta' and mode names.

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

Deploy Server

Other Tools