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

The description frames this entirely as a read operation ('Read saved Page lead forms') and reinforces the read-only framing with 'These tools never read private lead answers'. Annotations declare readOnlyHint=false and destructiveHint=true, so the description actively misdescribes the operational profile. No explanation is given for why a read of forms would be non-read-only or destructive, leaving the agent with a materially wrong safety model.

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 purpose is front-loaded in the first sentence, which is good. The second sentence is syntactically compressed to the point of ambiguity ('genads_ad_action action lead_forms, optionally formId'), and the closing warning about private lead answers is only loosely connected to the rest.

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?

This is a 6-parameter tool with a nested arguments object and 5 required fields, yet the description says nothing about the required envelope parameters (work_id, request_key, expected_catalog_version) or the 'separate form permission' prerequisite it names without explaining. An output schema exists so return values need not be described, but for a tool whose annotation profile is destructive and open-world, the description is under-informative about consequences and prerequisites.

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 50%; read_skills, expected_catalog_version, and publication_proposal_id are documented in the schema, but work_id, request_key, and account_id are bare. The description adds real meaning for form_id (optional, selects exact form detail) and for account_id ('The selected Page comes from the connection'), though that latter sentence sits in tension with account_id being a required declared parameter. The remaining plumbing identifiers receive no explanation.

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 gives a specific verb and resource: 'Read saved Page lead forms or an exact form detail', scoped by 'under separate form permission'. It also distinguishes the adjacent path by naming genads_ad_action with action lead_forms for fresh checks. It stops short of distinguishing itself from the crowded lead_* siblings (lead_form_plans, lead_form_result, lead_form_review, lead_collection), which an agent could easily confuse with 'read lead forms'.

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?

There is one explicit routing hint: use genads_ad_action action lead_forms for a fresh check, optionally with formId. However, the phrasing muddles rather than clarifies which tool to call for which need, since 'Request a fresh check with genads_ad_action... optionally formId' sits inside a tool that itself reads forms by form_id. No when-not guidance relative to lead_form_plans/lead_form_result/lead_form_review is provided.

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