Skip to main content
Glama

Get AI access

get_ai_access
Read-onlyIdempotent

Use this tool when the user asks whether ChatGPT, Claude, Perplexity, Gemini or another AI reads their landing page (ランディングページ, ホームページ, Webサイト), which AI crawlers fetched it, or how many visitors AI assistants sent (「AI に読まれている?」「ChatGPT から来た人は?」).

Returns one page's AI access for 7d, 30d (default), or 90d; 180d, 365d, and all need Pro or MAX, as the other long periods do (AI reads were first recorded on 2026-10-25, so their days start there at the earliest; referrals cover the whole period, read from the long-term daily summaries for 180d, 365d, and all).

  • totals: ai (answer + crawl), answer (an AI opened the page because a person asked it something right then: ChatGPT-User, Claude-User, Perplexity-User…), crawl (AI crawlers: GPTBot, ClaudeBot, OAI-SearchBot, PerplexityBot…), and search (bingbot and Applebot, search crawlers that also feed Copilot and Apple's features, never counted in ai).

  • verification: the fetches by IP address check, each with the same four numbers. verified: from an IP address the agent's vendor publishes. noList: not checked (the vendor publishes no list, its list has no ranges of the IP address's family or wasn't refreshed for a week, or the fetch was recorded before the check); not checked doesn't mean fake. unverified: the vendor's current list covers that IP address family and the IP address isn't on it. unverified.ai ("self-named only", typically a scanner) is left out of totals and every list; unverified.search (bingbot, Applebot) stays counted, informational only. totals = verified + noList + unverified.search.

  • byVendor, byToken (each agent's User-Agent token: fetches counted, verified among them, unverified flagged, outside fetches except for search crawlers), byPath (site and path, no query), byDay.

  • referrals: visitors and pageviews whose utm_source or referrer names an AI assistant (ChatGPT, Perplexity, Claude, Gemini, Copilot, Grok, DeepSeek, Meta AI), with byAssistant. Assistants' apps send no referrer, so this is a floor. startDate and endDate are the days counted; coversPeriod false means a longer period could only be read for its last 90 days. visitorsMethod: unique_in_period (7d, 30d, 90d) or sum_of_daily_uniques (180d, 365d, all: each day's visitors added up, so someone who came on 3 days counts 3 times, as in the other long-term visitor counts). available false means page views couldn't be read right now, not zero.

  • liveDaysAvailable: today's and yesterday's AI reads are read live; false means they couldn't be read right now, not zero, so the totals leave those two days out. Agents are named by what the requests' User-Agents claimed; where the vendor publishes its IP addresses (OpenAI, Perplexity, Anthropic, Microsoft, Apple, DuckDuckGo, Google), each fetch is checked against them and the IP address is never stored. Only fetches of the live page are counted (not robots.txt or the sitemap). AI reads and referrals are on the workspace's days (fetchDayTimeZone, referralTimeZone; UTC when none is set); referrals for 180d, 365d, and all are on the days the daily summaries are cut in, which follow a zone change once it has finished rebuilding, as get_analytics_summary's long periods do. Right after the workspace's zone changes, AI reads stay in the earlier zone, as fetchDayTimeZone says, until an hourly run re-reads the page; fetchDayTimeZoneSince, when set, is the first day in fetchDayTimeZone, and earlier days are in the zone before. Neither is a page view or a visitor in get_analytics_summary.

Input Schema

NameRequiredDescriptionDefault
periodNoTime period. Defaults to 30d. 180d/365d/all require Pro or MAX plan.30d
siteIdYesThe ID of the page to read AI access for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / siteId / description
      Previous value: -"The ID of the site to read AI access for"New value: +"The ID of the page to read AI access for"
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, yet the description adds substantial behavioral context: Pro/MAX gating for 180d/365d/all, data first recorded 2026-10-25, IPs never stored, only live page fetches counted (not robots.txt/sitemap), and timezone behavior on zone change. It also preempts the most dangerous misreading by stating that available=false and liveDaysAvailable=false mean 'not zero'.

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

Conciseness3/5

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

The use-when trigger is correctly front-loaded and the bullet grouping of totals/verification/referrals helps, but the prose is extremely dense with nested caveats (fetchDayTimeZoneSince, rebuilt zone changes, floor semantics) that overwhelm scanning even though most are substantive. There is no output schema, so much of the length is justified, but it could be tightened.

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 and a highly complex return shape, the description carries the full documentation burden and does so thoroughly: it defines every top-level field group (totals, verification, byVendor/byToken/byPath/byDay, referrals, liveDaysAvailable) and their edge-case semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: period affects visitorsMethod (unique_in_period vs sum_of_daily_uniques), whether referrals coversPeriod, and which days are read live. siteId gains scope clarification ('One page's') that the schema's one-liner does not fully convey.

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 and resource ('Returns one page's AI access') and enumerates the exact question types it answers (AI reads of a landing page, which crawlers fetched it, AI-referred visitors). It explicitly separates itself from get_analytics_summary ('Neither is a page view or a visitor in get_analytics_summary'), which is the key sibling confusion risk.

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

Usage Guidelines5/5

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

Opens with an explicit use-when clause covering multiple phrasings, including Japanese user utterances ('「AI に読まれている?」「ChatGPT から来た人は?」'), so an agent can route on natural user language. It also states the negative boundary against get_analytics_summary, so the alternative is named and the exclusion is clear.

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.