Loading ToolBench
MCP server for performing PageSpeed Audits
The server defines one tool, run_pagespeed_test, with a complete JSON Schema input definition generated from Zod. The tool has a clear, descriptive description and reasonable parameter documentation. However, there are critical gaps: (1) no documented output schema describing what the PageSpeed API returns to the LLM; (2) no error handling guidance beyond throwing raw errors; (3) parameter descriptions lack format constraints and dependency information; (4) no pagination or result-limiting pattern despite potentially large API responses. The schema is well-formed with proper type definitions and enum constraints, which is a strength. The naming 'run_pagespeed_test' follows verb_noun convention clearly. Overall, the tool is functional but lacks production-grade robustness in error messaging and output documentation.
Run a PageSpeed Insights test on a URL. Tests page performance, accessibility, SEO, and best practices.
No documented output schema. The tool returns raw PageSpeed Insights API response (large JSON object) without documenting structure, field meanings, or what the LLM should extract. This violates the pattern that 'document the output schema so LLMs know what fields to expect.'
No result limiting or pagination. The PageSpeed API response includes extensive metadata, scores, and audits that can produce 50+ KB of JSON. The tool description does not mention result limits, and there is no filtering or pagination to constrain output. Large unstructured responses waste tokens and dilute signal for LLM reasoning.
Insufficient error handling guidance. When the PageSpeed API fails (non-200 response), the tool throws a generic error: 'PageSpeed API error: {statusText}'. The LLM receives no guidance on whether to retry, what the cause was (rate limit, invalid URL, missing API key), or what to do next. Per pattern:recovery-guide, errors must tell the LLM what action to take.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions lack format constraints and dependency hints. The 'locale' parameter description is bare ('Locale for the test'), LLMs don't know valid values (en, de, fr, etc.), expected format (RFC 5646), or whether invalid values are silently ignored. The 'category' description states 'Categories to audit' but doesn't explain the default ['performance'] will be used if omitted, or clarify dependency with other params.
API key as parameter creates security risk. Although documented as optional with fallback to GOOGLE_API_KEY env var, accepting the API key as a tool parameter means it could appear in agent traces, logs, or prompt history. Per pattern:secret-injection, credentials must never be tool parameters.
No timeout configuration. The tool calls an external API (PageSpeed Insights) without an explicit timeout. If the API hangs, the agent blocks indefinitely. Per error-classification pattern, external calls should have explicit timeouts with retry guidance.