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

While annotations already flag destructiveHint=true and idempotentHint=true, the description adds substantial context beyond them: it explains the replacement is destructive (overwrites, not merges), names the exact failure condition (422 when metadata.canModifyServiceList is false), and specifies the accepted item shapes. This is genuinely useful behavioral disclosure.

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?

Three dense, front-loaded sentences with zero filler: replacement semantics lead, item formats follow, failure condition closes. Every sentence earns its place.

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?

For a destructive mutation tool with no output schema, the description covers replacement semantics, item structure, the read-first workflow, and the failure mode. It omits any note on the response shape, but that is a minor gap against otherwise thorough coverage.

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 meaningfully exceeds it by detailing the two item shapes (structuredServiceItem with serviceTypeId from the location's category vs freeFormServiceItem with category/label), which the schema's generic 'accepted fields vary' text does not provide.

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 ('Replace the service list on a Google Business Profile location') with clear scope. An agent can immediately distinguish this mutation tool from the sibling google_business_service_list_get without opening either schema.

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?

Gives strong usage context: 'This is a full replacement, not a merge — send the complete list,' and the schema note directs reading the current list first. It also states the 422 precondition tied to metadata.canModifyServiceList. It stops short of explicitly naming the get sibling as the read-first step, so it's clear but not exhaustively routing.

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