market_validate_request

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral trait beyond annotations - 'Preview and validation never authorize execution' - which tells the agent this tool cannot trigger downstream authorized work. It does not disclose validation failure behavior or what the outcome is, but given the annotations the bar is modest.

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?

Two short sentences with no filler; the verb-first opener 'Validate...' is front-loaded and the guarantee about non-execution is placed second where it lands logically. Slightly more structure (maybe a one-line note about validation output) could have covered the only real gap, but as written every word earns its place.

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 tool taking a deeply nested 1-required-parameter schema, containing no output schema, and having little about schema descriptions, the omission of what validation actually returns (errors, report, success flag) is a major gap. The wording also gives no distinction from market_preview_request or guidance on where validation fits in the workflow with the five other siblings. The complexity bar is high, and this description does not meet it.

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%, so the description fully carries the responsibility for explaining the 'request' parameter, and it adds nothing beyond calling it 'one canonical Unified Market Evidence Request.' The word 'canonical' hints at a structured contract already defined by the schema, but there is no compensation for the missing description fields, and the agent is left to infer the meaning of nested required fields like execution_mode, data_needs, and targets from pale enum/type information alone.

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 specific verb ('Validate') and a specific resource ('one canonical Unified Market Evidence Request'), and the second sentence explicitly carves it out from execution ('never authorize execution'). It does not, however, differentiate from the directly adjacent sibling market_preview_request, whose name is the only signal for what makes validation distinct from preview.

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 gives no guidance on when to validate versus when to preview, read, or fetch evidence. The only inferred usage cue is a negative one - 'never authorize execution' - but nothing tells an agent that market_validate_request is the correct step before submitting, or which sibling covers the same input.

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