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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description is fully consistent — the tool is a safe, non-destructive audit surface. Beyond that, the description adds genuinely useful behavioral context the annotations cannot: the cost model per tier ($0.50/$1/$5), the account scoping, and the statistical methodology (Bonferroni-corrected, out-of-sample, K-tracking). This adds value above the structured annotations.

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 well-structured with headers and front-loads the critical 'start here, FREE at depth=0' information. However, it is verbose — pricing is repeated across tiers, and closing lines like 'Machine-readable so any AI can audit the statistical rigor' and 'Full transparency' add marketing flourish rather than operational content. It could be tightened without losing meaning.

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 with 8 optional parameters, paid tiers, and no output schema, this description is thorough: it defines what each depth returns, how pricing works, what is scoped to the user, the filterable dimensions, and the drill-down sections. Combined with the annotations carrying the safety profile and the schema covering all parameters at 100%, 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 coverage is 100%, so the baseline is 3. The description substantially enriches the 'depth' parameter by explaining exactly what each tier returns and its price, which the schema's enum alone does not convey. The remaining parameters (market, status, edge_id, section, direction, timeframe, asset_class) are adequately documented in the schema itself, so no additional compensation is needed there.

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 opens with 'THE PRIMARY TOOL — start here' and names the specific verb+resource: a live feed of THIS USER'S OWN statistically validated trading edges. It distinguishes itself by explicitly stating what it is NOT ('it is NOT a general/shared library'), which separates it cleanly from the sibling 'search' and AI assistant tools.

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 three-tier structure gives explicit when-to-use guidance ('depth=0 (FREE — call this first)'), and the scoping exclusion ('NOT a general/shared library') rules out the wrong use case. It doesn't name a specific sibling as an alternative (e.g., directing to varrd_ai for general questions), but the 'start here' primacy plus clear tier semantics is strong practical routing guidance.

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