Skip to main content
Glama

SEO and Keyword Data API

Keywords shared by pages (up to 20 pages)

page_intersection
Read-onlyIdempotent

Page intersection: the Google keywords that up to 20 pages all rank for (minus keywords of up to 10 excluded pages), with each page's position, URL and estimated traffic plus search volume, CPC, difficulty and intent; up to 100 keywords in one $0.048 call. Use when you need the shared keywords of competing pages. Rows are capped at 200 / pages (2 pages: 100, 20 pages: 10). No shared keywords returns empty results (still charged). Bad input is free; upstream errors are not charged. Price: $0.048 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": {
      "pages": "<pages>"
    },
    "name": "page_intersection"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum keywords to return (1-200; lowered with a warning to 100, and to 200 / pages for more than 2 pages: 4 pages 50, 10 pages 20, 20 pages 10). Defaults to 20.
pagesYesPage URLs whose shared ranking keywords to find (1-20), e.g. ["https://example.com/guide", "https://example.org/guide"].
countryNoOptional ISO 3166-1 alpha-2 code or country name, used when locationCode is absent (uk = gb).
excludePagesNoOptional page URLs (1-10) to exclude: only keywords the pages rank for and these do not.
languageCodeNoLanguage code (2-letter). Defaults to en. An unsupported location falls back to 2840 (United States) with en (or the requested language if the United States offers it); a supported location with a language it does not offer uses that location's default language (en if offered). Either way market.fallback is true and market.warnings says what was used.
locationCodeNoGoogle Ads location code (geo target ID). Defaults to 2840 (United States); an unsupported code falls back to 2840 (United States, market.fallback).

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. Added

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds billing behavior (empty results still charged, bad input free, upstream errors free), a per-call price and the x402 payment mechanism, which is genuinely useful context beyond annotations. It does not add much beyond the annotations about the read-only/idempotent nature itself, so a 3 is appropriate for the added-value portion.

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 definition is a single dense paragraph, front-loaded with the purpose, then scope caps, then pricing. It is efficient overall, though the $0.048 price appears twice (once in 'up to 100 keywords in one $0.048 call' and again in the final price sentence), a minor redundancy.

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 names the returned fields (each page's position, URL, estimated traffic, plus search volume, CPC, difficulty, intent), so an agent knows what it will get back. It also covers cost, caps, and failure semantics, which is complete for a six-parameter 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 the schema already documents all six parameters with defaults and fallback rules. The description reinforces the page/exclusion caps and the row-cap formula (200 / pages, 2 pages: 100, 20 pages: 10), which adds meaning about the limit interaction but largely restates what the schema already says. Baseline 3 is correct when the schema carries the parameter detail.

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?

States a specific verb and resource: the Google keywords that up to 20 pages all rank for, minus keywords of excluded pages, plus the metric fields returned. An agent can tell this is an intersection/set-overlap tool rather than a single-page ranking list. It stops short of naming a sibling (e.g. keyword_gap or ranked_keywords) that would make the distinction airtight.

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?

'Use when you need the shared keywords of competing pages' gives a clear triggering condition. There is no explicit when-not guidance or pointer to the alternative tool for non-shared keyword sets, so the agent must infer the boundary against keyword_gap and ranked_keywords.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.