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

Discloses behavior well beyond the annotations: confirm=false is a preview and confirm=true actually publishes, the image is downloaded server-side by Google with hard constraints (public link, JPG/PNG, 250px short edge, 10 KB minimum), CALL CTAs omit cta_url because Google dials the business phone, and empty language falls back to the profile's own language then en. These are exactly the non-obvious traits annotations cannot express.

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 with the action and its surface, then ordered by decision relevance (CTA, image, language, safety, location). Dense but every clause carries operative information — no filler or restatement of the name/title.

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?

An output schema exists, so return values need not be enumerated, yet the description usefully notes that the button is read back from Google's reply as cta_type. With the preview/publish gate, helper routing, and full parameter semantics covered, an agent has everything needed to invoke it correctly.

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 0%, so the description carries the full burden and does: summary = post text, cta_type's six-value vocabulary plus the CALL-requires-no-url rule, cta_url requirement per type, image_url vs. gallery-photo distinction and format constraints, language semantics with fallback, confirm semantics, and location's accepted value forms. All 7 parameters are covered.

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 first sentence names a specific verb and resource: 'Publishes an UPDATE post (local post) to the Business Profile — visible on Maps/Search.' The scope (UPDATE-type local post, public surface) distinguishes it from siblings like gbp_update_post, gbp_list_posts, and gbp_create_location without opening their schemas.

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 clear conditional routing: 'If you do not have a public link, call upload_image first,' including the two distinct upload_image modes (source_url vs. no-args drop link) and how to obtain a location value from gbp_list_locations. It does not explicitly contrast create-vs-update (gbp_update_post), so it stops short of full alternative disambiguation.

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