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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuine behavioral context beyond them: the reader is deterministic, extracts only from the trader's own words, and outputs which required parts are missing, plus an explicit constraint not to invent parts.

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 front-loaded sentences with no filler; the purpose and output shape come first, then the usage directive. The 'way the studio does' framing and parenthetical seven-part list cost some space but carry real information.

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, so the description correctly carries the burden of describing the return: the filled 7 parts and the list of missing required parts. It is nearly complete, though it doesn't specify the exact output shape beyond the part names.

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?

With one parameter and 100% schema description coverage, the schema already defines the input fully. The description reinforces 'the trader's OWN words' but adds no syntax, format, or bounds beyond what the schema's 'in their words' already states.

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 ('read') and resource ('a trading idea'), and enumerates exactly what the deterministic reader produces: the 7 named parts plus a report of missing required parts. This distinguishes it from the sibling 'forge', which the description positions as the downstream step.

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?

It gives an explicit trigger ('Use it before restating or forging a rule') and names the alternative workflow ('forging'), which gives the agent a routing signal. It stops short of full when/when-not coverage, giving no conditions under which this should be skipped or is inapplicable.

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