Skip to main content
Glama
Sign In

Fudge for Shopify

by ai.fudge
OverviewDiscussionsAdmin

Check page speed

check_page_speed
Read-onlyIdempotent

Measure a store page with Google PageSpeed Insights: Lighthouse score and lab metrics, real-visitor Core Web Vitals and the largest improvement opportunities. Each device takes 10–30 seconds; results are cached for an hour. On a password-protected store, only real-visitor data is available.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_page_speed"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoA store URL or path, e.g. / or /products/blue-runner./
storeNoThe connected store to use. Omit when only one is connected.
deviceNoboth
domainNoThe Shopify storefront to check, e.g. example.com. Required until a store is connected; afterwards, omit it to use a connected store.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, open-world), the description adds three operationally important facts an agent cannot get from structured fields: per-device latency of 10–30 seconds, a one-hour result cache affecting freshness, and a degraded-data mode on password-protected stores. These directly shape whether and how an agent should call it.

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?

Three sentences, each carrying distinct information: what is measured, how long/cached, and the conditional limitation. Scope comes first and the caveat is last; there is no restatement of the title or filler.

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?

With no output schema, the description does the necessary work of naming the returned categories (scores, lab metrics, field CWV, opportunities). What is missing is minor: no indication of whether a failed or unthrottled run returns partial data, and no guidance on the store/domain pair for first-time use.

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 description coverage is 75%, so the schema already explains page, store, and domain, and the enum for device is self-evident. The description adds only indirect meaning to device via the per-device timing note, and gives no help on the store-vs-domain precedence question, which is the main ambiguity in this schema.

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

Purpose4/5

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

The description uses a specific verb (measure) and resource (a store page) and enumerates what is measured: Lighthouse score and lab metrics, real-visitor Core Web Vitals, and improvement opportunities, plus the underlying engine (Google PageSpeed Insights). It stops short of distinguishing itself from potentially overlapping siblings, so it is clear but not fully differentiating.

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

Usage Guidelines3/5

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

Usage context is implied by the naming of the measurement source and the note about password-protected stores, but there is no explicit when-to-use or when-to-prefer-another-tool statement. An agent can infer this is the page-speed measurement call, but nothing steers it away from adjacent audit tools if both apply.

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

All Fudge for Shopify toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources