Skip to main content
Glama
Akxan

google-seo-mcp

by Akxan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Core Web Vitals field history (CrUX)

crux_history
Read-onlyIdempotent

Track weekly Core Web Vitals trends (LCP, INP, CLS, FCP, TTFB) for a URL or origin using Chrome UX Report history, including distribution of good, needs-improvement, and poor experiences over time.

Instructions

Real-user Core Web Vitals trend from the Chrome UX Report History API for an origin or URL: weekly p75 of LCP, INP, CLS, FCP, TTFB over the last ~25 weeks with the share of good / needs-improvement / poor for each week. Use crux_snapshot for the latest record and the LCP sub-part breakdown. Needs the 'Chrome UX Report API' enabled on the GCP project and a key in CRUX_API_KEY / GOOGLE_API_KEY / PAGESPEED_API_KEY. Returns 404 when the page has too little traffic for CrUX; try the origin instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoorigin
weeksNo
targetYesPage URL or origin (https://example.com).
formFactorNoDevice class; ALL merges every device.PHONE

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.10.0
    • addedInput schema / properties / formFactor / description
      Added value: +"Device class; ALL merges every device."
    • changedInput schema / properties / formFactor / enum
      Previous value: -[
-  "PHONE",
-  "DESKTOP",
-  "ALL"
-]New value: +[
+  "PHONE",
+  "DESKTOP",
+  "TABLET",
+  "ALL"
+]
  2. Changed1 schema field changedv0.5.1
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observedv0.3.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/idempotent and non-destructive, so the description does not need to re-cover safety. It adds valuable behavioral context beyond annotations: it requires the Chrome UX Report API and one of the listed keys, returns 404 for low-traffic pages, and has a ~25-week history window.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded: the first sentence communicates the core function, metrics, and output; the subsequent sentences add routing, prerequisites, and an error-handling hint. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description rightly explains the return shape: weekly p75 values and good/needs-improvement/poor shares for each metric. It also covers authentication, error behavior, and the distinction from crux_snapshot, making the tool callable without guessing, though exact date/time-series formatting and pagination are not specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, with descriptions for target and formFactor but not scope or weeks. The description partially compensates by explaining the origin-or-URL input and weekly time span, but it does not clarify how the weeks parameter interacts with the mentioned ~25-week window or define the scope enum semantics beyond the parameter name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: it returns a real-user Core Web Vitals trend (LCP, INP, CLS, FCP, TTFB) from the CrUX History API for an origin or URL, including weekly p75 values and quality-bucket shares. It clearly distinguishes itself from the sibling crux_snapshot by saying to use crux_snapshot for the latest record and LCP sub-part breakdown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells the agent when to choose crux_snapshot instead (latest record, LCP sub-part breakdown) and gives a remediation path for the 404 low-traffic case: fall back to the origin. It also states the required API enablement and credential key names, so there is little ambiguity about prerequisites versus alternatives.

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

Deploy Server

Other Tools