PageSpeed Insights + Chrome UX Report MCP server (LH13-correct, CrUX History, key-ring, persistence)
Four tools with complete input schemas and descriptions. Naming follows verb_noun pattern (psi_audit, recommend, crux_query, ops). Descriptions are substantive (100-250 chars), exceeding the 10-char minimum. All parameters have type definitions and descriptions. However, output schemas are not formally documented in the source, only inferred from code comments. Error handling is comprehensive (TargetBlocked, QuotaCooldown, PsiRuntimeError, LabCwvMissing, ValueError) with recovery guidance via ErrorEnvelope, but tool descriptions do not explicitly state what errors are possible or how to recover. Parameter constraints (e.g., runs max 9, form_factor enum) are documented in descriptions but not enforced via JSON Schema enums. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present.
Chrome UX Report real-user field data for an origin/URL. Stateless.
Operational utility. action: keyring_stats | compat_status.
Run a full PageSpeed Insights (Lighthouse 13) audit for a URL: scores, Core Web Vitals, real-user CrUX field data, and the top optimization insights. Results are projected (LLM-sized) and persisted.
Deduplicated, prioritized performance recommendations for a URL (or a prior psi_audit run_id). Each maps to a canonical issue with authored fix steps; includes an instruction to synthesize the advice against the user's actual codebase.
Output schemas not formally documented. Code returns {content, structuredContent} but LLMs cannot see the structure of 'structuredContent' fields (run_id, data, recommendations, etc.). This forces LLMs to guess downstream field names and risks extraction errors.
'ops' tool is vague. Description says 'Operational utility. action: keyring_stats | compat_status.' but does not explain what these actions do, when to call them, or what they return. LLMs cannot determine when to invoke this tool.
Parameter constraints (runs max 9, form_factor enum PHONE|DESKTOP|TABLET, mode enum current|history|trend) are documented in descriptions but not enforced via JSON Schema enums or constraints. LLMs may pass invalid values; server must validate and return actionable errors.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All four tools are read-only (no state mutation), but this is not declared in the schema. Agents cannot infer safety properties without explicit hints.
Error handling is comprehensive in code (_guard function maps exceptions to ErrorEnvelope) but tool descriptions do not document possible errors or recovery steps. LLMs cannot plan error recovery without explicit guidance in the description.