Tools Reference

Run a comprehensive GEO readiness analysis on a domain. Checks robots.txt, llms.txt, homepage HTML (16 scoring categories), sitemap.xml, and security headers.

Analyze example.com for GEO readiness

• Overall GEO score (0-100) with letter grade
• The page type line: set by the assistant, or not confirmed with the detected type and why
• 16 category scores with pass/fail/warn checks
• robots.txt analysis with AI crawler access
• llms.txt presence and content preview
• Sitemap discovery status

Check a domain's robots.txt specifically for AI crawler access rules. Reports which crawlers (GPTBot, ClaudeBot, etc.) are blocked or allowed.

Which AI crawlers are blocked on example.com?

GPTBot, Google-Extended, CCBot, anthropic-ai, ClaudeBot, Bytespider, PerplexityBot, ChatGPT-User, AmazonBot, cohere-ai

Auditing your own site? Make sure GlippyBot itself is allow-listed — see the GlippyBot crawler info & allow-list guide for the User-Agent string and robots.txt snippets.

Check if a domain has an llms.txt file — the emerging standard for providing context to LLMs about a site's purpose and content.

Does example.com have an llms.txt file?

Run a live agent-access probe against one URL: 12 sequential requests from the machine running the server that differ only in User-Agent (a browser baseline, GlippyBot as a generic-bot control, 8 AI crawlers, a spoofed Googlebot, and a closing browser baseline). Only a difference between those same-IP requests counts as a block. A bare 403 can just mean the IP has a poor reputation, so anything short of differential evidence is reported as "could not tell from this vantage", never as blocked.

Can ChatGPT and Perplexity actually fetch https://example.com/pricing?

• A session verdict: open, ua_block, allowlist_block, verifies_identity, blanket_bots, vantage_blocked, rate_limited_vantage, inconclusive, or not_probed
• A state per probed crawler: ok, ok_degraded, ua_blocked, charged, inconclusive, or not_probed
• The control requests each verdict is judged against
• Impact by crawler role: blocks on citation crawlers cost GEO score, blocks on live fetchers are a lesser warning, and blocks on training crawlers are informational only
• A vantage caveat naming the network the probe ran from

Can AI and LLMs access my page? explains how the probe works and how to read each state.

Get a concise GEO readiness summary: overall score, grade, top 3 strengths, and top 3 issues. Use for quick assessments.

Give me a quick GEO summary of example.com

Extract one page's main content, cleaned and structured, so the AI model you are working with can judge what heuristics cannot: whether the positioning is distinctive or generic, whether claims are supported, which questions the page leaves unanswered, and which sections do not stand alone. It runs the same content engine as Glippy's content checks. Use analyze_urls when you want a scored audit instead.

It is also the first step of the classify-then-analyse flow: the output names the page type Glippy detected, with its reason, and lists every valid id, so the model can decide the type from the text and pass it to analyze_urls. The beta wording checks are never scored; the model may judge them itself from the returned sections.

Read https://example.com/pricing with extract_page_content and tell me which positioning lines are generic, which claims need evidence, and how to rewrite the sections that do not stand alone.

• Detected language, content type, and word count
• detected_page_type and detected_page_type_reason, page_type (whether a type was set), and valid_page_types (every id with a one-line description)
• Title, meta description, H1, and lead paragraph
• Sections in page order, flagged as self-contained, answer-first, or opening with a reference back
• The most quotable passages, statistical claims and proof points, and positioning sentences
• Content scores per category with their failing and warning checks
• A review guide that tells the model what to judge

Reads one public page as GlippyBot and checks robots.txt first. If the rules disallow the URL, or robots.txt cannot be read, nothing else is fetched and the tool explains why. See the GlippyBot crawler info.

Analyze multiple domains in parallel and compare their GEO scores side by side. Perfect for competitive analysis.

Compare GEO scores: example.com, competitor1.com, competitor2.com

Fetch a sitemap XML, extract URLs, and analyze each page. Supports regular sitemaps and sitemap index files.

Analyze all pages in https://example.com/sitemap.xml

Run GEO analysis on a specific list of URLs. URLs can span multiple domains.

Analyze these pages: https://example.com/about, https://example.com/pricing

Generate a styled, shareable report in Markdown or HTML format — matching the Glippy browser extension's export.

*Provide either domain or analysis_result

Generate an HTML report for example.com

Generate a styled report for bulk analysis: domain comparison, URL list, or sitemap crawl.

*Provide exactly one of: domains, urls, sitemap_url, or analysis_results

Generate an HTML comparison report for example.com and competitor.com

Some content checks only make sense for one kind of page: a product page is not expected to cite sources the way an article is, and an article does not need a price. Glippy used to guess the page type, and every serious content-check error came from a wrong guess. So the page type now comes from the AI assistant that calls the tools, through the optional page_type parameter of analyze_urls, analyze_domain, get_geo_summary, compare_domains and extract_page_content.

1. Decide what kind of page it is: look at it, or call extract_page_content, which returns detected_page_type with its reason, the list of valid ids, and the text.
2. Pass page_type to the scoring tool. Where your reading disagrees with the detected type, yours wins.

extract_page_content { "url": "https://example.com/pricing" }
  -> detected_page_type: "article", detected_page_type_reason: "Detected from og:type=article, ..."
analyze_urls { "urls": ["https://example.com/pricing"], "page_type": "product" }

Every check that depends on the page type is shown with its finding but carries no points, with the reason "Not scored: this check depends on the page type, which has not been confirmed." The other checks score as usual. "auto" is the same as leaving it out.

Only the ids below are accepted (case and surrounding spaces are ignored). Any other value is ignored with a note in the output (pageTypeNotes in JSON), and that page runs unconfirmed; there is no fuzzy matching. For the multi-URL tools, pass one id for every page or a map of URL (or domain) to id. Reports state the page type of every page, Page type: Article (set by the assistant). or Page type: not confirmed (detected: Article, from og:type=article, which many sites put on every page)., and flag a set type that Glippy's own detection disagrees with.

The domain tools analyse the homepage, which is usually homepage; a news front or blog index is index, a one-page local business site is service, a single-product site is product.

Every analysis tool accepts a render_mode parameter controlling how HTML is fetched for scoring. Some sites (Cloudflare, Akamai, DataDome, PerimeterX, Incapsula) block plain Node fetches; Chrome-backed modes drive a real browser to get past them. Auditing your own site? The cleaner fix is to allow-list the GlippyBot User-Agent — see the GlippyBot allow-list guide.

The returned analysis includes a renderMode field indicating which path ran:

Auto and chrome modes need a local Chrome/Chromium binary. The server auto-detects from CHROME_PATH, PUPPETEER_EXECUTABLE_PATH, or common install paths (Windows: C:\Program Files\Google\Chrome\Application\chrome.exe; macOS: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome; Linux: /usr/bin/google-chrome). If none is found, render_mode: "static" continues to work; other modes will record static-blocked.

Sites that fingerprint the headless build can still block the server-launched browser. Launch a separate Chrome with remote debugging and have the server attach to it by setting CHROME_REMOTE_URL in the MCP server env:

# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 --user-data-dir=/tmp/glippy-chrome &

# Windows (PowerShell)
& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --remote-debugging-port=9222 --user-data-dir=C:\Temp\glippy-chrome

# Linux
google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/glippy-chrome &

# Then in your MCP config env:
#   CHROME_REMOTE_URL=http://localhost:9222

Using a dedicated --user-data-dir keeps this session isolated from your normal browsing. When attached, the fetcher leaves UA/headers/stealth untouched so requests look identical to a human browsing from that profile.