Audits a site's robots.txt and llms.txt for access by Apple's Applebot-Extended AI crawler, returning per-crawler verdicts and an AI visibility score.
Audits a site's robots.txt and llms.txt for access by Google-Extended and other Google AI crawlers, with AI visibility scoring relevant to Google AI Overviews and Gemini.
Audits a site's robots.txt and llms.txt for access by PerplexityBot, reporting per-crawler verdicts and AI search visibility for Perplexity.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenGEO audit example.com for AI crawlers and give me its visibility score"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Open-source MCP server for AI search visibility (GEO / AEO). Give your AI agent real tools to audit and improve how your site shows up inside ChatGPT, Perplexity, Gemini and AI Overviews.
Free and open source. No subscription, no data warehouse account required.
SEO tooling is crowded. AI search tooling is not. OpenGEO focuses only on the layer the old suites ignore: can AI engines crawl you, cite you, and represent your brand.
Related MCP server: ai-visibility-mcp
npx opengeo-mcp{
"mcpServers": {
"opengeo": {
"command": "npx",
"args": ["-y", "opengeo-mcp"]
}
}
}audit_ai_crawlers - audits a site's robots.txt against 17 major AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended, Bytespider and more), checks for llms.txt, and returns a 0-100 AI visibility score with per-crawler verdicts.
list_ai_crawlers - lists every AI crawler OpenGEO knows about and what each one does.
Brand visibility checker - run a fan-out query set against ChatGPT / Perplexity / AI Overviews and report whether your brand is mentioned and how.
AEO schema audit - FAQ, speakable, authorship and entity markup checks for answer engines.
Citation tracking - which of your URLs actually get cited in AI answers, and how that moves over time.
FanoutQ integration - use FanoutQ as the query-expansion engine behind the brand visibility checker.
PRs welcome. The core logic lives in src/lib.ts and is framework-free, so you can reuse it in CLIs and tests.
MIT. An open-source project from the FanoutQ team.
Audit a site for AI search visibility: how robots.txt treats the major AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, ...) and whether llms.txt exists. Returns a 0-100 AI visibility score and per-crawler verdicts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The site to audit, e.g. https://example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses what is inspected and that it returns a 0-100 score with per-crawler verdicts, but it does not state whether the tool performs a live network fetch, has rate limits, or how failures are handled.
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 description is two tight sentences, front-loaded with the core purpose and followed by the return value. Every phrase contributes to understanding what is audited and what comes back.
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?
The description explains the checks performed and the shape of the return value, which is important because no output schema exists. It is largely complete for a simple single-parameter audit tool, though it could clarify operational behavior such as live fetching or scoring composition.
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?
There is only one parameter, url, and the schema description coverage is 100%, so the schema already documents its meaning and format. The description adds no parameter-specific details beyond the general audit context, making the baseline score of 3 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 and resource: auditing a site for AI search visibility, including robots.txt treatment of named AI crawlers and llms.txt existence. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling list_ai_crawlers tool.
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 use case is implied by “Audit a site for AI search visibility,” but there is no explicit guidance on when to use this tool versus list_ai_crawlers or when not to use it. The agent can infer the context, but alternatives and exclusions are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the AI crawler user agents OpenGEO knows about, with what each one is used for.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose the salient traits: this is a lookup of a predefined known set ('OpenGEO knows about') and the response includes usage purposes. It does not clarify whether the list is exhaustive, paginated, or static, but for a zero-parameter read-only reference the key behavior is conveyed.
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?
A single well-formed sentence that front-loads the verb and resource and adds the one useful detail (what each crawler is used for). No wasted text.
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 trivial zero-param list tool with no output schema, the description is close to sufficient, but it omits what separates it from audit_ai_crawlers and gives no hint about return size or ordering. An agent choosing between the two siblings still lacks the deciding detail.
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?
The tool takes no parameters, so the baseline is 4. Nothing in the description is needed to explain inputs, and none is given or required.
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 ('List') and resource ('AI crawler user agents') plus scope ('OpenGEO knows about'), and adds that each entry includes its purpose. It does not, however, distinguish itself from the sibling audit_ai_crawlers, so an agent must infer the difference.
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?
There is no explicit when-to-use guidance and no mention of audit_ai_crawlers as the alternative for actually probing crawlers. The only hint is the verb 'list', leaving the choice between the two sibling tools to inference.
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.
v0.1.0audit_ai_crawlerslist_ai_crawlersScored across 2 tools
audit_ai_crawlers performs an active site analysis, while list_ai_crawlers is a static reference enumeration of known user agents. The verbs and objects are distinct, and the descriptions reinforce the separation with no realistic chance of misselection.
Both tools follow the same snake_case verb_noun pattern (audit_/list_ + ai_crawlers), sharing the same domain object. Fully predictable and consistent.
Two tools is very thin for a server named OpenGEO, which implies generative-engine-optimization work well beyond a single crawler-access check. Only one functional tool plus one lookup helper leaves most of the apparent scope unaddressed.
The audit covers robots.txt verdicts, llms.txt presence, and a score, which is a coherent core, but there is no path to remediation (generating robots.txt rules or llms.txt), no inspection of llms.txt or sitemap contents, and no page-level content audit. Agents hit a dead end after diagnosis.
Score any website's AI search visibility out of 100 and see which of 20 AI crawlers can read it.
Checks llms.txt, AI crawler access in robots.txt, and sitemap - with a 0-100 AI readiness score.
Scan and fix your site's AI discoverability: crawler access, llms.txt, JSON-LD. Free.
Agent-readiness scanner (0-5 score), robots.txt + llms.txt generators, managed agent enablement.