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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, covering the safety profile. The description adds one behavioral detail — 'The first one becomes primary' — but omits permissions, duplicate handling, and what the call returns. With annotations doing the heavy lifting, this is adequate but thin.

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?

Front-loaded and efficient: purpose, primary-location side effect, then the minimum requirement, then the accepted keys. The key list is long but directly useful for callers; no filler sentences.

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?

The tool takes a nested profile object and has no output schema, so the description should carry more of the contract. It covers purpose, the primary side effect, and the city/address rule, but omits the required `site` argument, duplicate behavior, and any return-value expectations.

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 50%, and the description lists all accepted profile keys, largely duplicating the schema's property names while also adding a real cross-field rule: 'Give at least a city or an address.' It never mentions the required top-level `site` parameter or explains most nested fields, so it only partly compensates for the coverage gap.

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 states a specific verb and resource ('Saves a new business location') and adds that the first location becomes primary. It implies creation rather than update, which distinguishes it from update_business_location, but it never names an alternative or explicitly separates itself from a sibling like set_primary_location.

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?

No when-to-use guidance, no alternatives, and no prerequisites are given. The only instruction is a data requirement ('Give at least a city or an address'), which is validation rather than routing. An agent gets no help choosing this over update_business_location or set_primary_location.

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