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

Annotations only indicate non-read-only and non-destructive. The description goes far beyond that: it explains payment mechanics (send EXACTLY pay_exact_usdc from the funder wallet), the king-of-the-hill hold behavior, non-expiry until outbid, the 'purchase not deposit' nature, and the Authorization requirement. It also warns that shielded holders cannot be outbid until shield_until. This is exceptional behavioral disclosure for a financial action.

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 long and uses attention-grabbing caps, but nearly every sentence adds operational value: pricing, alternatives, payment flow, behavior, and auth. The most important call-or-not call information is front-loaded. It could be tightened, but it is not padded.

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?

With no output schema, the description carries the burden of explaining return value and post-call behavior, and it does: it returns the bid plus payment instructions including pay_exact_usdc, house_wallet, and a Solana Pay URI. It also covers authentication, the prerequisite read-board step, and what happens once payment lands. Nothing essential is missing for a payment tool of this complexity.

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 90%, so the baseline is 3. The description adds meaningful context beyond the schema: amount_usd means whole USDC at or above the take price, slug can be left empty to derive a word, tier maps to PLANET/MOON, and when is the agent-matching trigger. It does not add detail to every optional media parameter, but the schema already covers those.

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 uses specific action verbs ('Place a bid', 'buy yourself onto') and names the exact resources (AdSpace board, PLANET/MOON spots). It distinguishes from sibling tools by explicitly comparing with ads_order for ORBIT and clarifying that adspace_board is not a callable tool. An agent can tell exactly what this tool does without opening the 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 explicit when-to-use guidance: bid for held PLANET/MOON spots, and use ads_order for the ORBIT weekly ring instead. It also instructs the agent to read the board first via a public GET endpoint and explains how to determine the required price using next_min_usdc or take_usdc. This is strong routing behavior relative to siblings.

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