ygo_judge_card

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

With no annotations, the description carries the burden and does well: it discloses the data provenance mechanism (official/custom/generated/missing script status) so the agent knows data quality may vary, and states that rulebook and PSCT citations are attached to the answer. It omits whether a ruling is ever refused or degraded when the script is missing, which is the one meaningful behavioral gap for a no-annotation tool.

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?

Front-loaded with the usage imperative and the mechanic list, which is efficient. However, the closing 'Do not assert a ruling from memory. Do not answer from memory; call this tool first' says the same thing twice, and one of the two sentences should be cut.

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?

No output schema exists, so the description is responsible for describing returns, and it does so at a high level: adjudication plus script provenance plus rulebook/PSCT citations. For a 2-parameter read-style tool this is nearly complete; only the shape of the returned ruling (prose vs structured fields) is left unspecified.

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 coverage is 100% and both parameters are documented, so the baseline applies. The description's 'Accepts a passcode or a card name' usefully frames the two as alternatives rather than a pair, but that is largely restated by the schema's note that cardName resolves the passcode when omitted.

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?

States a specific verb and resource: full mechanics adjudication of a specific card's rulings sourced from the ProjectIgnis Lua script, listing the exact mechanic classes covered (HOPT/SOPT, cost vs effect, targeting, miss timing, Damage Step, negate activation vs effect). The scope phrase 'about a specific card' implicitly separates it from scenario/interaction siblings, but it never names ygo_judge_interaction, ygo_judge_scenario, or ygo_verify_ruling, so an agent must infer the boundary.

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?

Gives a strong positive trigger ('USE THIS for every ruling question about a specific card') and an explicit anti-pattern ('Do not assert a ruling from memory'), which is a real behavioral instruction rather than filler. It stops short of naming the alternative tools for multi-card interactions or general policy, so the when-not guidance is implied rather than enumerated.

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