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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral context about the return shape (customization tree, swappable choices, price deltas), which tells the agent this is a deep-detail call rather than a flat record. It does not mention auth, rate limits, or whether any choices are unavailable at a given store.

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 that front-loads the resource ('Burger King item, combo, or picker full detail') before enumerating the customization variants. No filler or repetition. Dense, though the colon-list makes it a slightly heavy read.

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 enumeration is not required, and the description still usefully sketches the customization tree. Combined with 100% schema coverage and read-only annotations, an agent has what it needs to call this correctly. Only the lack of alternative-tool routing keeps it out of the top band.

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%, so the schema already documents market, item_id, and store_id including their source endpoints. The description's phrasing 'item, combo, or picker' for the item_id domain adds a little meaning, but on the whole it defers to the schema, which is the correct baseline-3 outcome.

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 names a specific resource (Burger King item, combo, or picker) and states it returns full detail plus a customization tree, with concrete sub-cases (combo courses, picker variants, item ingredient toggles). An agent can distinguish this from burgerking_menu (listing) and burgerking_locations. It does not, however, explicitly name which sibling it supersedes, so sibling differentiation is implied rather than stated.

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?

The description itself gives no when-to-use or when-not-to-use guidance. Usage is only inferable from the schema, where item_id is documented as coming 'from /burgerking/menu' and store_id 'from /burgerking/locations', which implies this is the follow-up detail call. That is a reasonable workflow signal but falls short of explicit routing.

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