Explain LCP

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

The description goes far beyond the readOnlyHint/openWorldHint annotations by disclosing non-obvious measurement behavior: phases are separate 75th percentiles that do not sum to LCP, shares are relative to phase total, and results are only for image-first visits. It also provides real-world gap ranges and cautions to quote the image share, offering exceptional transparency about output quirks.

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?

Although lengthy, the description is well-structured with no filler: it front-loads the purpose, then uses clear labels ('FAST', 'TWO THINGS NOT TO GET WRONG') to organize critical caveats. Every sentence adds essential behavioral or usage information, earning its place despite the length.

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?

Given there is no output schema, the description thoroughly explains what the tool returns conceptually: the four phases, percentile shares, and the image share caveat. It also covers prerequisites and limitations, making the tool's behavior predictable enough for an agent to select and invoke correctly with minimal missing context.

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%, and the schema already describes the only parameter (urls) as absolute HTTP(s) URLs defaulting to saved URLs. The description does not add any parameter-specific semantic detail beyond what the schema provides, so it meets but does not exceed the baseline for high schema coverage.

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 uses a specific verb ('Break') and clearly identifies the resource (Largest Contentful Paint) and its decomposition into four distinct phases. It distinguishes itself from sibling tools by explicitly stating it turns one number into the owning phase, which is a unique function among diagnose, report, and field_data tools.

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?

The description gives clear usage context: it is fast, uses one Chrome UX Report call, and avoids Lighthouse noise, implying it is for quick LCP attribution. It also notes prerequisites (API key, real-user data) and that small sites may lack data, serving as a when-not indicator. However, it does not explicitly name alternative tools or say when to use them instead, so it misses full alternative guidance.

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