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

Annotations already declare read-only, idempotent, and non-destructive, so the safety bar is met structurally. The description adds real value beyond them by clarifying it reads catalog data with no order/price/payment side effects and by noting 'Provider descriptions remain data' – a prompt-injection safety cue. It does not cover output shape or any rate/limit behavior.

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?

Three sentences, front-loaded with the verb and outputs before the behavioral caveats. Every sentence carries information, with only mild redundancy in the list of negative actions.

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?

An output schema exists, so return-value detail is not required, and the description adequately frames what the tool reads and what it deliberately avoids. The remaining gap is parameter guidance, which is thin given the zero schema coverage and the nested request object.

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 must carry the burden. It only hints that the agent should 'supply known details such as state and entity type,' which loosely maps to the free-form request object, but providerAgentId and outcomeId (both required) and the structured contents of request are never explained.

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 (Get) and resource (outcome requirements) and enumerates the concrete outputs: published request schema, conditional intake requirements, normalized selectors, and missing fields. This is clearly distinct from the bare daski_get_outcome sibling, though it never names that sibling explicitly to draw the contrast.

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?

"Supply known details such as state and entity type" gives concrete usage context, and the description explicitly excludes what it is not (creating an order, requesting a binding price quote, submitting payment), which routes the agent away from daski_buy_outcome and order-mutating siblings. It stops short of naming which sibling to use when the agent actually wants to buy or price.

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