Skip to main content
Glama
mriver15

getcompetitive

by mriver15
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Record a generated set

record_set
Idempotent

Save a generated Pokémon set to the local per-user store for later retrieval, validating species, item, nature, and spread; illegal sets are rejected and unknown moves become warnings.

Instructions

File a Pokémon Champions set the reasoning produced into the local, per-user record, so a set generated once can be read back later — get_set returns it under recorded when asked with includeRecorded. The usage-derived meta (list_threats, get_set) stays the only home of measured usage: a record carries no rank, no usage share and no sample, and is labelled with how it was arrived at — "inferred" (solved from battle observations) or "proposed" (generated for a team). The store is one JSON-Lines file per user, $GETCOMPETITIVE_STORE or ~/.getcompetitive/sets.jsonl, created on first write; re-recording an identical set is a no-op (created: false) and a changed spread, item or move set is filed as a new record, so the file is the timeline of what was generated. The set is resolved against the dataset with the same rules the rest of the server uses, so an unknown species, item, nature or an illegal spread is rejected rather than filed, while unknown moves come back as warnings and the set is filed as given. This is the only tool on the server that writes anything; where there is no writable filesystem (the hosted endpoint) it returns an isError naming the path it could not write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
setYesThe set to file, in the canonical shape `parse_team`, `diagnose_team`, `infer_set` and the analysis tools all consume.
noteNoWhy this set exists — the question it answers or the evidence behind it; carried verbatim into the record’s `origin`.
toolYesWhich part of the reasoning produced it, e.g. "infer_set", "diagnose_team", "optimize_team"; carried verbatim into the record’s `origin`.
basisYesHow the set was arrived at: "inferred" when it was solved from battle observations, "proposed" when the reasoning generated it for a team. Neither is measured usage.
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.
regulationNoRegulation the set was generated for, e.g. "m-c"; when given it must resolve, and it becomes part of the record’s identity.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv8.0.2

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the annotations: it discloses the JSON-Lines store path, creation-on-first-write, the no-op behavior for identical records, new-record behavior for changed content, dataset validation with rejection versus warnings, and the error path on non-writable filesystems. These details match and enrich the idempotentHint annotation without contradicting it.

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 description is long but dense, and the core purpose is front-loaded. Each later block earns its place by covering a distinct concern: provenance, storage, idempotency, validation, and deployment failure. A few parentheticals, such as the usage-derived meta note, are somewhat knotted, but there is no real padding.

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?

For a write tool with no output schema, the description covers the essential runtime context: file location, append semantics, record identity, validation behavior, failure mode, and idempotency. The one notable gap is the full success response shape — only `created: false` is mentioned — so an agent is left to infer the rest of the return structure.

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 already strong. The description adds meaningful parameter context: basis labels are tied to inferred versus proposed, the set is resolved with server-wide rules, illegal spreads are rejected while unknown moves become warnings, and regulation becomes part of the record's identity. This supplements the schema rather than merely repeating it.

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 concrete action and resource: file a Pokémon Champions set into the local per-user record for later read-back via get_set. It clearly separates this write tool from the get_set read path and from analysis siblings, and it names itself as the only writing tool on the server, removing ambiguity about its role.

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 says when to use the tool — when reasoning produced a set that should be persisted — and where to read it back: get_set with includeRecorded. It also states the hosted endpoint has no writable filesystem and will fail, which is a practical exclusion. This gives an agent a clear decision rule.

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