ygo_consistency_lab

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

With no annotations, the description carries the full burden and does so well: it discloses that hands are seeded, run through the real ocgcore engine, played with a heuristic AI while the opponent passes, and always stopped after turn 1. It also explains the metrics and their meaning, including that anyActionRate is 'a very low bar'. It does not discuss runtime cost or how the result should be interpreted beyond the measurement framing, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is four tightly written sentences, front-loaded with the core action and followed by mechanics, metrics, and a scope caveat. Every sentence contributes information an agent needs, and nothing is repeated from the schema. The structure moves cleanly from purpose to method to output to interpretation.

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

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

For a seven-parameter tool with no output schema and no annotations, the description is substantially complete: it explains the simulation method, the reported metrics, and the interpretation limit. The main remaining gap is that it does not state that a deck must be supplied via 'input' or 'main'/'extra', even though no parameters are marked required. Runtime cost is also not mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all seven parameters are already documented by the schema, which sets the baseline at 3. The description adds general context about seeding and the opponent passing, but does not add meaning to individual parameters beyond what the schema states. For example, it does not clarify how 'input' and 'main' interact or when to use one over the other.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource: measure a deck's opening hands by dealing seeded hands through the real ocgcore engine, playing one turn, and reporting named rates. It also separates itself conceptually from win-rate prediction ('A measurement, not a win-rate prediction'). It stops short of naming a specific sibling tool that would be preferred for actual duels, so the differentiation is implicit rather than explicit.

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

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

Usage guidance is implied rather than stated: the definition tells you what is measured and that it is not a win-rate prediction, which suggests when the output is appropriate. It does not explicitly say when to choose this over ygo_run_duel, ygo_simulate_duel_scenario, or ygo_ai_benchmark, nor does it state exclusions. The line 'A measurement, not a win-rate prediction' is a useful hint but not a full routing rule.

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