Measure a page with PageSpeed Insights and compare it with its copy sped up by WebSpeed Fast.
Scored across 2 tools
The two tools have clearly distinct roles: measure_site starts an asynchronous measurement and returns an audit_id, while get_measurement retrieves status or results for that audit_id. Their descriptions explicitly reference this handoff, so an agent should never confuse which tool to call.
Both names use consistent snake_case and a verb-first pattern: measure_site starts work and get_measurement retrieves its outcome. The slight noun difference reflects the different objects being acted on, not an inconsistency in convention.
Two tools are fewer than the typical 3–15 range, but the async job pattern inherently requires one tool to start a measurement and one to retrieve its result. Each tool earns its place, though the surface is minimal.
The core lifecycle—starting a PageSpeed measurement and polling/retrieving its result—is fully covered. Minor operations such as cancellation or listing past audits are absent, but they are not essential for the stated workflows.
Status or result of a measurement started with measure_site. While running, returns the queue position or progress. When done, returns the verified comparison and what else slows the page down. Quote numbers only from this result and keep its wording about estimates; if it says there is nothing to judge, do not invent numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| audit_id | Yes | audit_id from measure_site |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/non-destructive, so the description's real contribution is the state machine (queue position or progress while running, verified comparison when done) plus a data-integrity rule about quoting and estimates. Missing is anything about how long a measurement typically takes or how often to poll.
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 the core purpose, then the two states, then the quoting constraint. Three sentences with no filler; the final sentence's 'do not invent numbers' is defensive but carries genuine instruction value for a results tool.
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 bears the burden of describing return values; it does so at a functional level (queue position, progress, verified comparison, other slowdowns) without detailing field structure. For a one-parameter read-only poll tool this is nearly sufficient, though a hint on result shape would complete it.
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 single audit_id parameter is fully documented in the schema as 'audit_id from measure_site'. The description adds no syntax, format, or validity detail beyond that, so the baseline of 3 applies.
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?
States a specific verb+resource ('status or result of a measurement') and anchors it to its producer: 'started with measure_site'. The two-state return (running vs done) makes it immediately distinguishable from the sibling measure_site.
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 dependency on measure_site is explicit, and the running/done branches tell the agent what to expect on each call, implying a polling pattern. It does not state outright that the agent should re-call until completion, nor any polling cadence, so guidance is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a real PageSpeed Insights measurement of a web page: the original site vs. its copy accelerated by WebSpeed Fast (mobile and desktop). Returns an audit_id immediately; the run takes 2–5 minutes, and get_measurement reads it when the user asks. If the page was measured before, its full result is returned at once. Results are published as a report page on webspeed.pro. Use when the user asks why a site is slow, how fast it is, or what can be sped up.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page address, e.g. example.com or https://example.com/pricing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the asynchronous behavior: it returns an audit_id immediately, the run takes 2–5 minutes, and get_measurement reads it later. It also explains caching behavior (a previous measurement returns its full result at once) and that results are published as a report page on webspeed.pro, which is valuable context for an open-world, non-destructive measurement tool.
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 description is dense but well organized: action and return value first, then timing, retrieval via get_measurement, caching behavior, report publishing, and finally when to use it. Every sentence contributes useful information without repetition.
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 single-parameter tool with no output schema, the description covers what the tool does, what it returns immediately, how long the run takes, how to retrieve the result, caching behavior, and where the report is published. An agent has enough context to call it and route follow-up reads to get_measurement.
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?
There is only one parameter and the schema description coverage is 100%, so the schema already explains that url accepts addresses like example.com or https://example.com/pricing. The description adds context about what is measured but no additional parameter syntax or constraints 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: it starts a real PageSpeed Insights measurement of a web page, comparing the original site against a WebSpeed Fast-accelerated copy on mobile and desktop. It clearly distinguishes the action from the sibling get_measurement, which reads the result.
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?
It gives explicit use cases ('why a site is slow, how fast it is, or what can be sped up') and explains that get_measurement retrieves the eventual result. It does not explicitly state when not to call measure_site, such as when an existing measurement should simply be read, but the sibling relationship is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_measurementmeasure_siteGoogle PageSpeed Insights — runs Lighthouse against any public URL and returns the performance…
Google PageSpeed Insights (Lighthouse) scores, Core Web Vitals and top speed fixes for every URL...
Lighthouse scores, Core Web Vitals (LCP, CLS, INP/TBT) and top fixes for any URL, mobile or desktop.
Website performance monitoring: scans, Core Web Vitals, RUM data and alerts.
Add one secure layer between your agents and this server.