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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the disclosure that results are partial and category-limited: unknown or unavailable values are expected, video capability must not be inferred from photo capability, and booking links may be absent. That is real behavioral context beyond the annotations. It stops short of saying what an 'unknown' value looks like in the response.

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?

Two sentences, front-loaded with the enumerated payload and followed by a single constraint sentence; nothing is wasted. The first sentence is a dense noun-phrase list rather than a clause with an explicit verb, which slightly slows comprehension but costs no 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?

With no output schema, the description does the work of enumerating the returned data classes (attributes, booking/ordering links, menus, lodging, services), which is enough for an agent to predict the payload. The main residual gap is the shape of the response and how unavailable/unknown entries are represented, given the explicit warning that they occur.

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 both site_id and user_goal are already documented in the schema, including the guidance to omit personal details from user_goal. The description adds no parameter-level meaning beyond that. Baseline 3 is appropriate when the schema carries the full burden.

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 the specific resource set it returns: attributes with current values, booking/ordering links, menus for food businesses, lodging details, and services. That is far more informative than the title alone and makes clear this is a category-scoped read of one location's Google data. It does not name sibling tools such as get_google_profile or get_google_business_summary, so an agent must infer the boundary itself.

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?

There is an implied precondition ('only for what the location's Google category supports'), which tells the agent the category must already be known, and a downstream caution about never recommending unavailable booking links. But there is no explicit when-to-use versus alternatives — nothing points to search_google_categories for category resolution or to a sibling for basic profile fields. Usage is inferred rather than stated.

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