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

Goes well beyond annotations by disclosing the access tier, the independence assumption, same_game flagging behavior, failure behavior when a leg matches no fair line, and a caution against presenting EV as a profit guarantee. It also describes key response fields even though annotations already cover safety.

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?

Dense but front-loaded and information-rich; every clause contributes. Minor density from nested parentheticals, but it avoids filler.

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 does a good job naming returned fields and failure behavior. The notable omission is the devig parameter and when to choose multiplicative versus shin.

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 only 33%, so the description should compensate more. It clarifies the 2-15 leg range and that offering a price yields offered_ev_pct, but it never mentions the devig parameter or its enum options, and individual leg fields are left largely to the schema.

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 ('Fair price of a parlay across games'), including leg range 2-15 and the pricing basis. It is clearly distinguishable from siblings such as propline_get_event_ev and propline_price_sgp.

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?

Explicitly names the alternative propline_price_sgp and the condition selecting it: same-game parlays, since this tool assumes independent legs and flags same_game. It also states the 2-15 leg constraint and that the endpoint is Hobby+.

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