Skip to main content
Glama
Sign In

SEO and Keyword Data API

by com.duoleads.keywords
OverviewDiscussionsAdmin

Page speed (Lighthouse Core Web Vitals)

pagespeed
Read-onlyIdempotent

Page speed of one URL from a real Lighthouse run: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift and Speed Index with their scores, the performance score when reported, final URL and version, mobile or desktop, $0.018 a call. Use when checking Core Web Vitals. A page that fails to load or whose report is too large is a charged answer (status failed / too_large). Bad input is a free 400; a refunded or failed run is not charged. Price: $0.018 per successful call, paid over x402 (USDC on Base); pass the payment in _meta["x402/payment"].

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "pagespeed"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesAn http(s) URL of a public page (domain name, default port); without a scheme, https:// is assumed.
strategyNoDevice to emulate. Default mobile.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous value: -"An absolute http(s) URL of a public page (domain name, default port)."New value: +"An http(s) URL of a public page (domain name, default port); without a scheme, https:// is assumed."
  3. Added

TDQS

A4.1/5.0
Behavior5/5

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

The annotations already mark this as read-only, open-world and idempotent, and the description adds substantial behavior beyond them: charge semantics for failed/too-large runs, free 400 for bad input, no charge for refunded/failed runs, and the required x402 USDC-on-Base payment in _meta["x402/payment"]. Those are exactly the operational facts an agent needs before invoking a paid external call.

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

Conciseness4/5

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

The structure is front-loaded with the metrics and use case, then the pricing and failure semantics, with zero filler sentences. The one inefficiency is stating the price twice ("$0.018 a call" and "Price: $0.018 per successful call"), which is a minor redundancy in an otherwise dense paragraph.

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

Completeness5/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 carries the return-value burden and does so by naming the metrics, scores, final URL and version. It also covers the failure modes (status failed / too_large) and payment mechanics, which is everything an agent needs for a two-parameter, paid, read-only tool.

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 both url and strategy are already documented in the schema, including the https:// default and the mobile default. The description only echoes "mobile or desktop" and "one URL" without adding format or constraint detail beyond the schema, so the baseline 3 applies.

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 names a specific resource (one URL) and verb-like operation (a real Lighthouse run) and enumerates the exact metrics returned: FCP, LCP, TBT, CLS, Speed Index, plus performance score, final URL and version. That is far more than a restatement of the name. It stops short of explicitly distinguishing itself from the overlapping sibling on_page_audit, so it is clear but not fully sibling-differentiated.

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 gives a direct when-to-use trigger: "Use when checking Core Web Vitals." That is a real selection signal for an agent scanning many SEO tools. It does not name an alternative (e.g. on_page_audit) or state when not to use it, so it is clear context without exclusions.

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

All SEO and Keyword Data API 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