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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real behavior beyond that: CRM-connection conditionality for last-submission data, bot-check detection, and the fact that forms blocking automated tests end with a manual 30-second human test. 'Changes nothing' reinforces the read-only annotation rather than contradicting it.

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 purpose, then the enumeration of findings, then usage triggers, then the no-side-effects note. The middle is a long run-on clause chain that could be tightened, but every element carries information and nothing is filler.

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 carries the return-value burden, and it does so by enumerating what the test reports (form tool, redirect target, tag presence, bot checks, last submission). Combined with annotations covering safety and open-world scope, an agent has enough to invoke it correctly, though pagination/result-shape specifics are absent.

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, so the schema already explains 'client' (from list_clients) and 'pages' (extra landing page URLs). The description only alludes to 'any pages given' without adding format, count, or ordering guidance. Baseline 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?

Opens with a specific verb+resource ('Test a client's lead forms') and then enumerates the actual outputs: every form on home/contact/quote/extra pages, form tool name, post-submit destination, Google tag presence, bot checks, and last submission date. This is clearly distinguishable from siblings like lead_forms, lead_check, and site_check.

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?

Explicitly states when to use it: 'Use when leads drop, after any change to a form, or to set up tracking.' That is clear triggering context. It does not, however, name a sibling alternative (e.g. lead_check or site_check) or state when-not-to-use, so it stops short of the top band.

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