Skip to main content
Glama
mriver15

getcompetitive

by mriver15
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Optimize team slots

optimize_team
Read-onlyIdempotent

Fill open team slots by scoring Pokémon that cover missing types and answer specified threats, returning ranked recommendations with reasons for legal, regulation-valid teams.

Instructions

Pokémon Champions team building: fill open slots against constraints: "cover these types" and "answer these threats." The engine scores every legal species in the regulation against the constraint set — the types the current team never hits super-effectively (computed automatically, or supplied), and the threats named or defaulted to the meta’s top five by usage — by what its typing covers, resists and hits, with a small preference for species the meta actually plays. With two open slots it scores pairs on their combined coverage, not just the sum. Every recommendation carries the reasons, so the tradeoff is visible; unranked species are scored on typing alone because their movesets are unknown. The fills respect Species Clause and stay inside the roster, so the result passes check_legality — verify with it once the team is assembled. Read-only and offline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
teamYesThe team so far, in the canonical shape `parse_team` returns; the open slots are what this tool fills.
slotsYesHow many members to recommend: one species, or a pair whose combined coverage is scored together.
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.
playstyleNoShorthand for the objective: "tailwind" or "trick-room" map to the corresponding required role; any other value is carried into the note verbatim.
coverTypesNoTypes the finished team must hit super-effectively, e.g. ["Water", "Steel"]; omitted, the engine computes the types the current team cannot hit at all.
regulationNoRegulation id, e.g. "m-c"; omitted, the current set is used and its roster bounds the candidates.
answerThreatsNoSpecies the finished team must answer, e.g. ["Sneasler", "Gholdengo"]; omitted, the regulation’s five most-used threats are used.
requiredRolesNoCompetitive roles the filled slots must collectively provide, e.g. ["tailwind", "fake_out"]; candidates earn score for roles the team still lacks.
excludedSpeciesNoSpecies to exclude from the search, e.g. ["Milotic"]; case- and punctuation-insensitive.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv8.0.2
    • removedInput schema / properties / team / items / properties / teraType
      Removed value: -{
-  "description": "Tera Type carried verbatim from a Showdown paste; Champions math ignores it.",
-  "type": "string"
-}
  2. Addedv6.2.2

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnly/idempotent/destructive annotations by explaining the scoring algorithm, default to the meta's top five threats, pair-based scoring for two slots, the unranked-species limitation, and the Species Clause/roster constraints. It also explicitly says "Read-only and offline," adding context consistent with 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads the purpose, and every following sentence carries useful behavioral detail. It is longer than strictly necessary, but for a complex optimization tool the density is justified and there is no filler.

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?

Given the tool's complexity, nine parameters, no output schema, and rich annotations, the description covers the core behavior, defaults, constraints, and even output detail levels through the detail parameter. It could be more complete by explicitly mentioning how requiredRoles and excludedSpecies influence the search in prose, but the schema covers those and the description provides enough 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value by explaining how coverTypes and answerThreats interact with scoring, what happens when they are omitted, and how two slots are evaluated jointly. It does not discuss every optional parameter such as playstyle or requiredRoles, but those are already well-described 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 and resource: "fill open slots" in a Pokémon Champions team, scoring legal species against coverage and threat constraints. It clearly distinguishes this from analyzer/calculator siblings by describing a search-and-recommend engine rather than a generic analysis. The scope is immediately apparent.

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

Usage Guidelines4/5

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

"Pokémon Champions team building: fill open slots" gives clear context for when the tool is appropriate, and the closing instruction to verify with check_legality implies the downstream workflow. It does not name alternative sibling tools or explicitly state when not to use it, so it stops short of full routing guidance.

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