swu_sideboard

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions 'reset playtest zones' as a side effect, but it does not reveal whether the operation is destructive, requires specific permissions, how it affects game state, or whether swaps are reversible. This is a mutation tool, and the lack of detail about consequences is a significant gap.

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 a single, concise sentence that directly states the main action and a secondary effect. It contains no filler, and every word contributes to understanding. The structure is front-loaded with the primary action ('Swap cards') and follows with the consequence, making it easy to grasp quickly.

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?

Given the tool's complexity—'swaps' is a loosely defined array of objects, and there are no annotations—the description is incomplete. It does not explain how to specify swaps, what exactly 'reset playtest zones' entails, or any constraints on session_id. The output schema exists but does not compensate for the lack of behavioral and parameter context.

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 0%, and the description provides no explanation of the 'swaps' or 'session_id' parameters. The 'swaps' parameter is an array of objects with additional properties, making its structure ambiguous, yet the description offers no guidance on how to format swaps. The description entirely fails to compensate for the schema's lack of documentation.

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 clearly states the tool's function: 'Swap cards between the main deck and sideboard, then reset playtest zones.' It uses a specific verb ('swap') and identifies the resources (main deck, sideboard) and an additional side effect (reset playtest zones). This distinguishes it from sibling tools like swu_upload_deck or swu_move_card, which handle different deck operations.

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?

The description implies the tool is used for sideboard adjustments during playtesting ('then reset playtest zones'), but it does not explicitly state when to use it versus alternatives or provide any exclusions. There is no mention of prerequisites or situations where another tool would be more appropriate, leaving usage context largely implied.

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