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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds genuinely useful behavior: async polling bounded to six reads, missing values are not zero, and results stay in call history. However, 'Prices and publication are unapproved' is opaque and reads like boilerplate unrelated to a Lighthouse audit, muddying rather than clarifying behavior.

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 body is short and telegraphic, but the first sentence merely repeats the title and several later sentences ('Prices and publication are unapproved') are cryptic filler. Front-loading the title restatement instead of the actual operation is a structural miss.

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?

No output schema exists, so the description must carry return-value context — and it does name 'Lighthouse laboratory facts' with explicit missing-evidence markers and a bounded read count. Parameter coverage is still thin, keeping this from being fully self-sufficient.

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 0% across two parameters, and the description never mentions the required 'url' (maxLength 2048) or the 'device' enum (DESKTOP/MOBILE, default DESKTOP). With zero schema-level documentation and no compensating description text, an agent learns nothing about parameter meaning, valid values, or device defaults from prose.

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 opens by restating the title verbatim ('Page Lighthouse Laboratory Evidence') and never supplies a verb for what the tool does. 'Bounded Lighthouse laboratory facts' lets an agent infer a Lighthouse lab audit on a page, but there is no explicit statement of action, scope, or how it differs from siblings like nexscope_page_loading_waterfall, nexscope_page_screenshot, or nexscope_website_page_checks.

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?

No guidance on when to choose this over the many page-audit siblings, and no prerequisites or exclusions. 'Seven-day source-freshness rules apply only to dependent requests' is a policy constraint rather than a usage instruction, and 'one submit and at most six fixed reads' describes mechanics without saying when the tool is the right pick.

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