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

Annotations already flag destructiveHint=true and non-idempotence, but the description earns its keep by explaining the actual behavior: it returns an approval link, the org's policy check and daily post cap still run, and rejected posts are kept as flagged rather than published. That tells the agent the write is deferred and may silently not go live, which annotations alone cannot convey. It does not cover retry/duplicate behavior for a non-idempotent call.

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 short sentences with the action and outcome up front, then the scheduling detail, then the policy caveat. Every clause carries information an agent would otherwise have to guess at.

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 approval flow and policy behavior are well covered, and there is no output schema to explain. But for a 15-parameter tool with two enums and internal conditional requirements, the description leaves the agent without guidance on which fields are mandatory for OFFER/EVENT posts or how the button fields relate.

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?

With 15 parameters and only 33% schema description coverage, the description must carry conditional semantics and it largely doesn't; it only adds that scheduled_at is ISO 8601. It never explains that event_*/coupon_code/terms_conditions are tied to post_type EVENT/OFFER, or that cta_url is required except for CALL — the highest-risk mistakes an agent could make here.

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?

It states a specific verb and resource ('Ask the user to approve a new Google Business Profile post') and scopes it to creation of a new post, published immediately or scheduled. The approval-request framing cleanly separates it from the draft_* and request_update_post siblings, which is exactly the distinction an agent needs before picking a tool.

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?

It makes clear the tool is for approval-gated publishing and explains both modes ('published now or scheduled'), including the parameter that selects scheduling. It stops short of naming alternatives (list_posts, request_update_post, request_delete_post) or stating exclusions, so it is clear context without explicit routing.

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