List Google Business Profile Posts

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds '0 credits' and 'Needs Google Business Profile connected,' which are operational prerequisites and cost details not covered by annotations. It also discloses the state field's possible values, enriching beyond the structured data.

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 description is a single, information-dense sentence that front-loads the core purpose ('List the Posts currently on the brand's Google Business Profile listing') and follows with the returned fields and usage guidance. No wasted words; every clause adds value.

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 read-only list tool, the description is comprehensive: it details the returned fields, including state enums, gives usage scenarios, notes the prerequisite of a connected profile, and credits cost. With no output schema, this description gives the agent everything needed to call and interpret the result 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 100% for both parameters: limit has 'how many to return, max 100 (default 20)' and locationId has 'which listing, from list_business_locations — only needed when there is more than one.' The description does not add any new meaning beyond what the schema already provides, so a baseline of 3 is appropriate.

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 clearly states it lists the Posts on the brand's Google Business Profile listing, enumerating the fields returned (text, topic type, state, button, timestamps). It distinguishes itself from sibling tools like list_google_business_reviews (reviews vs. posts) and delete_google_business_post (listing vs. deletion) through the verb and resource specificity.

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?

The description explicitly states two usage scenarios: 'to see what is already showing before writing another' (implying before post_to_google_business) and 'to get the id of one to remove' (implying before delete_google_business_post). This gives clear when-to-use guidance without needing to name alternatives directly.

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