Skip to main content
Glama
Sign In
Site Audit MCP Server

Site Audit MCP Server

by steadfeed-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Bulk PageSpeed / Lighthouse audit

audit_pagespeed
Idempotent

Measure page performance by running Google PageSpeed Insights on URL lists, sitemaps, or same-domain crawls across mobile and desktop and collect aggregated scores.

Instructions

Run Google PageSpeed Insights (Lighthouse) on a list of URLs, a sitemap, or a same-domain crawl, on mobile and/or desktop, with aggregated scores. Requires your own free Google PageSpeed Insights API key (googleApiKey, or the GOOGLE_PSI_API_KEY environment variable when running locally). Each URL x device is one billed audit.

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": "audit_pagespeed"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlsNoPages to audit.
dryRunNoPreview with built-in sample data; no website is contacted and the cost is minimal.
strategyNoDevices to test (default mobile).
maxAuditsNoSafety cap on audits (default 20 here).
maxCostUsdNoOptional hard cap in USD for this call. The underlying Actor stops when the cap is reached. Minimum 0.05 (the Apify per-run minimum). Default: a small amount computed from the number of URLs, never below 0.05.
sitemapUrlsNoSitemap URLs to discover pages from.
googleApiKeyNoYour Google PageSpeed Insights API key (free).
maxCrawlPagesNoMax pages from the crawl (default 20).
crawlStartUrlsNoStart pages for a same-domain crawl.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses two things an agent cannot glean from structured data: an external auth requirement (your own Google PSI key, or GOOGLE_PSI_API_KEY when local) and the billing model ('each URL x device is one billed audit'). That cost/auth context is exactly the kind of behavioral disclosure that prevents surprise spend.

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, front-loaded with the action and input modes, then the prerequisite, then the cost rule. No filler, no restatement of the name or title, and the most decision-relevant constraints appear before the credential detail.

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?

For a nine-parameter, zero-required-parameter tool with no output schema, the description covers auth, cost, and modality well. The notable gap is that it never states the input-mode constraint (that at least one of urls, sitemapUrls, or crawlStartUrls must be provided) nor what the aggregated return looks like, which matters given required parameters is empty.

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 100%, so the schema already does the heavy lifting for all nine parameters; baseline is 3. The description adds modest meaning on top: the environment-variable fallback for googleApiKey and the per-URL-per-device billing rule that governs how strategy and maxAudits translate into cost, but it does not clarify the relationship between urls/sitemapUrls/crawlStartUrls or what happens when none is supplied.

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 ('Run') and resource ('Google PageSpeed Insights (Lighthouse)') and enumerates all three input modes (URL list, sitemap, same-domain crawl), the device dimension, and the output shape ('aggregated scores'). This is specific enough to distinguish it from siblings like audit_accessibility or audit_ai_crawler_access without opening any schema.

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

Usage Guidelines4/5

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

It clearly frames the three ways to feed the tool (list of URLs / sitemap / crawl) and the mobile-vs-desktop choice, plus the upfront credential prerequisite. What it lacks is any explicit 'use X instead when...' routing or exclusion, so an agent must infer alternatives from sibling names alone.

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