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

Annotations already declare read-only/non-destructive, and the description adds substantial behavior beyond that: offerings are paged 60 at a time cheapest-first with a next_offset, `live_data` appears only when the business runs a connected system, connector-sourced offerings carry variants with `inventory` (null = unknown), and `connected` actions must be taken via place_order/book_slot. Residual gaps are modest (no statement of what an unknown/absent business returns, no rate or size limits beyond the 200 cap already in the schema).

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 opening is well front-loaded ('Free. One business in full'), but the body is one dense run-on paragraph built from stacked parentheticals that mix return-shape documentation, pagination rules and connector semantics. Individual clauses earn their place, yet the packaging makes the routing information harder to extract than it needs to be.

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?

There is no output schema, so the description carries the burden of describing the return value, and it does so thoroughly — record sections, pagination, connector variants, inventory semantics, and the delivery/action vocabulary. The one missing piece an agent would want is how this differs from get_business.

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 real meaning: it explains the paging model (offerings_page reports the total and the next offset) and ties the id back to its source (the business id from search_catalog). It stops short of restating what offerings_limit/offset do numerically, which the schema already handles.

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 makes clear this retrieves a single business in full and enumerates the components of the record (identity, offerings, actions, delivery methods, freshness). However, it never distinguishes itself from the sibling tool get_business, which on its face sounds like the same operation, so an agent cannot tell them apart from the description alone.

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 gives concrete triggering questions («can they deliver to me», «are they open now», «what else do they do») and a fallback case after search_catalog returns a business with nothing listed. It also points to server instructions. What it lacks is any when-not guidance or an explicit routing rule against get_business/find_business.

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