Free AI visibility check: can AI crawlers read a site, and do ChatGPT, Gemini, Perplexity cite it?
Scored across 3 tools
The three tools have largely distinct roles: check_ai_visibility performs a live site check, get_public_report only reads a stored report, and get_tool_info is pure metadata. The first two both return AI visibility information and could be momentarily confused, but the descriptions clearly delineate 'fetches the website' versus 'reads stored report only'.
All three names follow a clean verb_noun snake_case pattern: check_ai_visibility, get_public_report, get_tool_info. Verbs (check/get) match the action type and there is no mixing of conventions.
Three tools is lean but fits the narrow, single-purpose scope of a free visibility checker. It is on the thin side, yet each tool covers a distinct need (run check, fetch stored report, explain the tool).
For a read-only free checker the surface covers the core lifecycle: perform a check, retrieve a prior report, and learn about the tool. The full live AI-answer check is deliberately offloaded to the external site, which is a documented limitation rather than a hidden gap.
Free AI visibility and GEO (generative engine optimization) check for a company website by QQQ (qqq.ee). Checks whether AI crawlers (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended ...) may read the site, plus robots.txt, sitemap, Organization structured data, indexability and llms.txt, and returns the latest public report of brand mentions and citations in ChatGPT, Gemini and Perplexity answers when the domain has been checked before. The full AI answer check (brand visibility in live AI answers) runs on qqq.ee: the result always includes a prefilled link. Limited to a few checks per day; read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Public website domain or URL, for example example.com or https://www.example.com/. IP addresses and private hosts are refused. | |
| language | No | Language of the answer and of the qqq.ee links: en (English, default) or et (Estonian). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds valuable non-annotation context: a rate limit ('limited to a few checks per day') and the behavior that the result always includes a prefilled qqq.ee link for the full check that runs externally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single long sentence front-loads the core purpose well, but then cascades into a dense list of checks and cross-site behavior. It is informative and not padded, yet the run-on structure with parenthetical branding ('by QQQ (qqq.ee)') makes it harder to scan than a short purpose sentence followed by separate usage/rate-limit notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description covers purpose, the checks performed, rate limits, and the external full-check workflow. It is nearly complete; it only lacks explicit when-not-to-use guidance and a note that results may be partial when the domain has no prior check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both 'domain' and 'language' fully, including the IP/private-host refusal and the enum meanings. The description adds no parameter-level detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('AI visibility and GEO check for a company website') and enumerates exactly what is inspected: AI crawler access, robots.txt, sitemap, Organization structured data, indexability, llms.txt, and brand mention reports. It is clearly distinguishable from the only sibling, get_tool_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it ('when the domain has been checked before' for the report portion) and notes that the full live AI answer check runs on qqq.ee, but it never states when NOT to use this tool or how it differs in intended purpose from get_tool_info. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the latest public AI visibility report of a domain from QQQ (qqq.ee), when someone has already run the full check on qqq.ee: report date, market and field, in how many search-grounded ChatGPT, Gemini, Perplexity and Claude answers the company was named, how often its own website was cited, a summary per AI engine, the questions asked, the cited source domains and short answer excerpts, plus the link to the report page. Reads the stored report only: no website is fetched, no AI model is asked and no new report is created. Without a report, says so and links the full check on qqq.ee. Read-only, no limit.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Website domain or URL, for example example.com or https://www.example.com/. | |
| language | No | Language of the answer and of the qqq.ee links: en (English, default) or et (Estonian). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by stating that no website is fetched, no AI model is queried, and no report is created, plus the no-report behavior and 'no limit'. The 'Read-only' phrasing partly restates readOnlyHint=true, but the negative-scope disclosure is genuinely additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and the long enumeration of returned fields is informative rather than padding. The single dense paragraph is slightly list-heavy but every sentence carries content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned payload (report date, market/field, engine coverage, citations, questions, excerpts, report link). An agent knows both what it gets back and the no-report case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the domain format and the en/et language enum are already documented in the schema. The description adds no syntax or default guidance beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the latest public AI visibility report of a domain') and immediately scopes it to stored reports only. It is clearly separable from the sibling check_ai_visibility, which it implicitly contrasts with by noting that no new report is created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition ('when someone has already run the full check on qqq.ee') and describes the fallback when no report exists. It does not name check_ai_visibility as the tool to use to run the check, leaving the sibling routing slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describes the free QQQ AI Visibility Checker (qqq.ee): what it measures (brand mentions and website citations in ChatGPT, Gemini and Perplexity answers, AI crawler access, technical readiness for AI search / GEO), its limits, and the English and Estonian links to the web tool and full reports. No cost, no website is fetched.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language of the answer and of the qqq.ee links: en (English, default) or et (Estonian). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: no cost, no website is fetched (external network is not touched), and the answer's scope including both language variants of the links.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then a tight parenthetical listing of what the answer contains; every clause carries information. It is a single fairly long run-on sentence, which costs it the top mark.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a trivially simple one-param input, the description tells the agent what the returned content covers (measurements, limits, links) and what it does not do (fetch a website). Only the shape of the return (prose vs structured) is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single optional 'language' parameter with 100% schema coverage, so the schema already documents the en/et enum and default. The description only echoes this indirectly ('English and Estonian links') and adds no new syntax or behavior beyond the structured data, making 3 the correct baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Describes the free QQQ AI Visibility Checker') and then enumerates the exact subject matter the answer covers (measurements, limits, links). The closing 'no website is fetched' implicitly separates it from the sibling check_ai_visibility, which an agent can act on without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the tool reads as the orientation/meta entry point before or instead of running an actual audit, and 'no cost, no website is fetched' hints at when it is the cheaper option. It never names check_ai_visibility or states an explicit condition for choosing one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_public_reportcheck_ai_visibilityget_tool_infoFree AI visibility (GEO/AEO) audit: can ChatGPT, Claude and Perplexity find and cite your website?
Checks whether a website is readable and citable by AI systems (ChatGPT, Claude, Perplexity, etc.)
Free AI visibility and GEO audit: see what AI reads on your site and whether its answers cite you.
Checks whether ChatGPT, Gemini and Perplexity cite your site, and who they cite instead.
Add one secure layer between your agents and this server.
