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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true). The description adds genuinely new context: posts are publicly visible the instant they are created, which is the key irreversible consequence an agent must weigh before confirming. It stops short of saying whether a created post can be edited or deleted afterward.

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 tight clauses with no filler, and the core action is front-loaded ahead of the safety note. The "(update)" parenthetical is the only slightly wasteful/ambiguous element.

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?

No output schema exists, so the description would ideally say what a successful create returns (post ID, resulting URL), and it says nothing about rate limits or per-location post quotas. Still, for a 6-parameter create tool with rich schema docs and annotations, the essential call-time and consequence information is present.

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 83% and the schema already documents the confirm gate, CTA URL requirement, photo constraints and summary length. The description only restates that CTA and photo are optional and never mentions gbp_location_id or its sourcing from gbp_list_locations. Baseline 3 applies when the schema carries the load.

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 ("Publish a post ... on a Business Profile location") and enumerates the content it carries (text, CTA button, photo). The parenthetical "(update)" gestures at Google's terminology but is not fully explained, and the sibling gbp_posts (which likely reads posts) is never named, so differentiation is inferred rather than stated.

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?

"Preview unless confirm is true" gives a usable operating rule, but that rule is already spelled out in more detail in the confirm parameter schema. Nothing tells the agent when to create a post versus reviewing existing posts via gbp_posts, and no prerequisites (e.g. connected profile) are stated.

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