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

Annotations already declare readOnlyHint: true, so the safe, non-mutating nature is covered. The description adds value by disclosing return behavior: 'Returns the most recent Lighthouse result and up to 7 historical data points for trend analysis.' This tells the agent about the data scope and limit without contradicting annotations.

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?

Two concise sentences with no wasted words. The first sentence front-loads the primary purpose, and the second adds useful return information. Every sentence earns its place, making the description efficient and easy to scan.

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?

For a simple one-parameter, read-only tool with no output schema, the description is adequately complete. It names the metrics returned, the source (Lighthouse), and the historical window (up to 7 points). A fully explicit response schema would be nice, but the current description gives an agent enough to invoke correctly and anticipate the result.

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%: monitor_id is already described as a UUID. The tool description adds no extra parameter-level detail, so with full schema coverage the baseline of 3 applies. The description's mention of 'for a specific monitor' reinforces the parameter but does not add new semantics beyond 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?

The description states a specific verb and resource: 'Get the latest page speed score and Core Web Vitals (LCP, TBT, CLS) for a specific monitor.' It clearly indicates the tool returns recent Lighthouse data and historical points. However, it does not explicitly differentiate from closely related siblings like run-page-speed-check or analyze-crux-trend, relying on the 'latest' phrasing to imply read-only retrieval.

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 implies usage: call this when you need the current page speed score for a monitor. It does not explicitly state when to use an alternative (e.g., run-page-speed-check to trigger a fresh check) or provide exclusionary guidance. This is better than no guidance but leaves the selection decision somewhat implicit.

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