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

Annotations only declare read safety; the description adds substantial non-obvious behavior: floor-first row ordering, the dominance rule ('a row shown only when it is cheaper than every row in front of it'), fee-inclusive pricing at party size, and that fan listings open to offers are included. Critically it discloses a data gap — no specific cheapest fan ask is surfaced — preventing the agent from fabricating one.

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?

Front-loaded with the usage trigger and no filler sentences; every clause carries either output semantics or a reporting constraint. The middle sentence is a long chained clause enumerating the matrix structure, which costs some readability but the content justifies the length.

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 three-parameter read tool with an output schema and read-only annotations, the description covers the remaining burden: what the matrix contains, how rows are ordered and filtered, and how the agent should present results. The 'do not describe the market with averages, medians, or maximum asks' directive closes the main misuse risk.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining that prices are 'fee-inclusive per ticket at the party size,' clarifying quantity's effect on the returned numbers rather than just filtering. Sections are only indirectly referenced via 'per section's rows,' so it stops short of full extension.

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 ('Returns XP's ticket price matrix from the connected order book') and immediately distinguishes itself from row-browsing siblings with 'not just browse rows.' The detailed content of the matrix (per seat level, floor first, rows front to back) makes the tool's output shape unmistakable relative to search_market or get_ticket_listings.

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?

Gives a clear triggering condition ('when the user wants to understand what an event is trading at') and an explicit negative condition ('not just browse rows'), which implicitly routes the agent away from listing-browse tools. It never names a sibling tool outright, so the alternative is inferable rather than explicit.

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