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

Annotations only declare readOnlyHint=false and destructiveHint=false, and the description goes well beyond that: it discloses the fail-closed validation rules (known features/ops, stop loss, bounded sizing), the three artifacts created on the caller's account, the exact success/failure response shapes, and that a non-validating spec is not an error. Auth requirements and the 'no money moves' constraint are also stated.

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 purpose and side effects, and the response-shape and error semantics are worth their space. Slightly dense and mildly redundant ('paper testing' vs. 'Paper only — no money moves'), but every sentence carries information an agent needs.

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?

There is no output schema, and the description compensates by enumerating the return object fields and the failure branch. Auth, validation, side effects, and error-vs-success semantics are all covered, so nothing an agent needs to call it correctly is missing.

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 the baseline is 3. The description still adds meaning by spelling out what makes a spec valid (known features and ops, a stop loss, bounded sizing) and reinforcing the 'none' sentinel, which enriches the spec parameter beyond the schema's terse note.

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 (submit), a specific resource (a desk-engine strategy spec), and the scope (paper testing via the desk lab), then enumerates exactly what gets authored on submission (skill, rig, schedule). No sibling tool does anything comparable, so an agent can place it unambiguously.

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 clear context for use — paper testing only, fail-closed validation, 'none' submits nothing — and states preconditions (signed-in, open to the founder's account unless the lab is opened). It does not explicitly name an alternative tool or a when-not-to-use condition, but none of the siblings overlap, so the guidance is adequate rather than complete.

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