tab_price_slip

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses the critical decoToken binding mechanic, that per-leg errors appear in the response body rather than as HTTP failures, and that auth works without a key while env vars unlock more. It also provides the return shape. No contradiction with 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-organized into purpose, return shape, token rationale, sibling comparison, error behavior, and auth. The capitalization and repeated 'twin' phrasing are slightly redundant, but every section contributes operational 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?

With no output schema, the description compensates by giving a concrete return structure including uuid, clientDetails, bets, legs, decoTokens, and odds. It also covers the workflow constraint, per-leg error handling, and auth requirements, making it complete enough for correct invocation.

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?

The input schema covers all 6 parameters with detailed descriptions, including the exact bets payload, string types for stake/odds, integer propositionId sources, jurisdiction list, and defaults. Tool description therefore doesn't need to repeat parameter semantics; schema coverage is 100%.

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 a specific action and resource: 'PRICE A BET SLIP on your own account and get the decoTokens that tab_place_bet requires.' It clearly distinguishes itself from tab_sgm_price as the account-tier twin, so an agent can identify what this tool uniquely does.

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 explicitly explains when to use this tool instead of the sibling: tab_sgm_price is for comparing prices across books, while this one is 'for the moment before placing.' It also instructs the sequence — price with this tool, then place with the returned tokens and never with tokens from an older enquiry.

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