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

Goes well beyond the annotations: it discloses that Google Ads is never mutated, that changes stay inside this server, that the monthly change limit is unaffected, and that every operation is a two-call preview/confirm flow with a confirm_token accepted for 10 minutes. This is exactly the kind of side-effect, reversibility, and confirmation context annotations cannot convey.

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-loads the core purpose and the dispatch example before enumerating operations, which is the right ordering for an agent. There is mild redundancy ('nothing in Google Ads' and 'never counts toward the monthly change limit' are each stated twice), but the length is justified by the non-obvious two-call protocol.

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?

With no output schema, the description steps in and describes what the first call returns (a preview with confirm_token), which is the critical return-shape information. For a non-destructive, non-idempotent wrapper with richly annotated safety hints, this covers everything an agent needs; extra detail on error handling or token expiry behavior would be the only remaining gap.

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 action/tool_name/arguments are already documented, but the description adds the operative semantics: that the same tool_name and arguments must be reused across both calls and that 'connection' is required when multiple ad accounts exist. The 10-minute confirm_token validity is additional information not present in the schema.

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 ('Creates this server's monitors for a Google Ads account') and immediately disambiguates from the sibling operate-in-Google-Ads tools with 'Nothing in Google Ads changes.' An agent can tell this is a monitor-creation wrapper, not a Google Ads write, without inspecting the 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 clear context for when to call it (watching campaigns/ad groups, triggering email when a rule holds) and routes the agent to get_tool_schema and google_ads_read {"action":"list_tools"} for operation discovery. It does not explicitly state when to prefer it over siblings like build_campaign, but there is no true alternative for monitor creation.

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