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

Annotations already declare this a read-only, idempotent, open-world check, so the safety profile is covered, and the description layers on substantially more: the capability status vocabulary (available / not_applicable / not_implemented / not_connected / insufficient_permission / unavailable_from_google / discontinued / unknown), the instruction that unknown or missing capabilities are treated as unavailable, and the meaning of null connect_url and pro_required. It also flags that assistant_context is authoritative, which tells the agent where the ground truth lives. No contradiction with the read-only annotation.

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 core question is front-loaded in the first clause, and every subsequent sentence maps to a real decision the agent must make. The cost is that it is one undifferentiated paragraph with a long parenthetical enum dump, which makes it harder to scan than a short bulleted status→action mapping would be. Slight over-packing, but little genuinely wasted wording.

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 full burden of explaining return semantics — and it does, enumerating capability statuses, what `choices` and `connect_url` mean, what a null connect_url implies, and what assistant_context is for. For a read-only status-probe tool with only one required parameter, an agent has everything needed to call it and interpret the result.

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%: site_id is documented as the site whose GBP location to use and user_goal as an optional plain-words goal. The description adds essentially nothing about either parameter — the only identifier it discusses (connection_id) belongs to the sibling choose_google_location, not to this tool. Baseline 3 is the correct ceiling when the schema already carries the parameter 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 opening sentence names a specific verb and resource set: whether a Google Business Profile is connected to a site, which location, its health, and its capabilities. That is far more than a restatement of the name and makes the tool's scope unambiguous. It stops short of a 5 because it never distinguishes itself from the many adjacent Google siblings (get_google_profile, get_google_business_summary, list_google_locations), so an agent must infer the boundary from the name 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 explicit branch-by-branch routing: not_selected/ambiguous → ask owner to pick from `choices` by connection_id and call choose_google_location; not_connected → hand over `connect_url`; available=false → state GBP is unavailable for the workspace; pro_required → relay pro_message first. It also states a hard gating rule that only `available` capabilities should be offered. This is exactly the when/when-not guidance an agent needs before acting on the result.

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