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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context on top: null means 'not declared/unknown, never no', isOpenNow is computed in the venue's own timezone and is null when hours are unknown, close_minute > 1440 wraps past midnight, VERIFIED only when human-verified, TABLE_AVAILABLE only from staff-confirmed tables, and an access restriction (public-directory opt-in only).

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 action is correctly front-loaded in the first clause, but the remainder is one enormous run-on sentence with no grouping or line breaks, making the field list hard to scan. The length is partly justified by the absent output schema, yet the structure is poor.

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 the full job of documenting the return surface — hours encoding, null semantics, derived channels/policies, verification and channel states, and visibility scope. Only not-found/error behavior is left unstated, which is minor for a read tool whose annotations cover the safety profile.

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?

There is a single parameter with 100% schema description coverage (including a concrete slug example), so the schema carries this dimension. The description repeats that the lookup is by slug but adds no format, casing, or resolution rules beyond 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 ('Fetch a public restaurant profile by slug') and enumerates exactly what is returned. It distinguishes itself implicitly from search_restaurants/get_restaurant_menu via the slug-based single-venue fetch and the 'public directory' scope, but never names the siblings it is not.

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: you must already hold a slug, and the note that 'Only restaurants opted into the public directory are visible' is a visibility constraint rather than when-to-use guidance. No explicit routing to search_restaurants for slug discovery or to get_restaurant_menu for menu-only reads.

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