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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuinely new behavioral context by disclosing the credit cost ('Costs 0 action credits'), which is decision-relevant and not encoded in any structured field. It stops short of noting rate limits or whether an event can return zero markets.

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?

A single sentence with the resource scope front-loaded and the cost note appended where it is most useful. No filler, no redundancy with the title, and nothing an agent must skim past.

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 an output schema present, the description need not explain return values, and both parameters are fully documented in the schema. The cost disclosure covers the main non-obvious behavior. Slightly incomplete in not stating whether the response is paginated or what happens when an event has no listed markets.

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 100%, with both bookmaker and event_id documented including example formats, so the schema carries the semantic load. The description only restates that the call is scoped to one event_id on a bookmaker, adding no format or constraint detail beyond the schema. Baseline 3 applies.

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 a specific verb ('Fetch') plus a precise resource list ('canonical markets, lines, outcomes, and live odds') scoped to one event_id on one bookmaker. It is unambiguous what the tool returns, though it never names a sibling such as mbc_list_markets to distinguish the event-scoped call from catalog-level listing.

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?

Usage is only implied: the schema note 'Event ID from mbc_search_events' hints at the search-then-fetch workflow, and 'for one event_id on a bookmaker' implies single-event scope. There is no explicit statement of when to prefer this over mbc_list_markets or other alternatives, and no exclusions.

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