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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the economically critical behavior: the budget is debited up front, each buy is an auction starting near the current price, the maxPrice cap is enforced per settlement unit, minimum buy size is $25, and there is no start/stop fee. It also confirms the return shape is unsigned transactions in order and that nothing is sent or signed, which is exactly the context needed to use the tool safely with annotations present.

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?

A single long sentence, but front-loaded with purpose, then mechanism, then fees, then return contract; each clause carries information an agent needs. The density costs a little readability, which keeps it from a 5.

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 7-parameter financial tool with no output schema, the description covers the pipeline, fee and safety story well, but leaves a real gap: neither days nor hours is required in the schema and the description does not say the caller must pick exactly one, nor what happens on omission or conflict. It also does not restate the 'listed' constraint as a validation rule.

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 71%, and the description adds real meaning beyond the fields: maxPrice is framed as a hard ceiling per 1 token of settlement, budget is tied to the up-front deposit, and 'days (or hours)' explains the two duration parameters. It does not clarify that days and hours are mutually exclusive duration choices, so it falls short of full coverage.

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 and resource ('Build a recurring buy of a listed ST0x stock token') and immediately defines the mechanism that separates it from a one-off trade: the whole budget is deposited up front and spent over days or hours. An agent can distinguish this from market_trade or place_limit_order without opening any schema.

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 clear context for when this applies (spreading a budget into multiple buys over a time window) and hints at the stop counterpart with 'No fee to start or stop.' It does not explicitly name an alternative tool or state exclusions (for example, when a single market_trade would be preferable), so it stops short of a 5.

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