The ai-visibility-mcp server audits and fixes how AI systems (ChatGPT, Claude, Perplexity, etc.) see and access a website, closing the full audit-to-fix loop in a single session.
Audit Tools:
check_ai_bot_access(domain): Analyzes robots.txt and Cloudflare settings to determine allow/disallow status for 22 known AI user-agents (GPTBot, ClaudeBot, PerplexityBot, etc.).
audit_ai_visibility(domain): Generates a 0–100 AI visibility score with explainable deductions covering robots.txt rules, meta tags (noai/noimageai), JSON-LD structured data, sitemap.xml, llms.txt, and SPA shell detection.
check_llm_mention(brand, query, aliases?, models?): Queries multiple LLMs simultaneously (Perplexity Sonar, GPT-4o-mini, Gemini 2.0 Flash by default) to measure brand/product presence in AI-generated answers, with per-model mention status, citation counts, and share-of-voice.
compare_competitors(your_domain, competitor_domains): Runs parallel visibility audits across your domain and up to 10 competitors, returning a ranked side-by-side comparison of scores, blocked bots, JSON-LD presence, llms.txt, sitemap size, and Cloudflare state.
Fix-Generation Tools:
generate_robots_patch(domain, allow_bots?, deny_bots?): Produces a corrected robots.txt that unblocks AI bots while preserving existing rules.
generate_json_ld(url, page_type?): Generates Schema.org JSON-LD structured data for a page, with auto-detection of page type.
generate_llms_txt(domain, crawl_depth?, max_pages?): Crawls the site's homepage and sitemap to produce a spec-compliant llms.txt file.
Analyzes website visibility by detecting Cloudflare's AI bot blocking defaults and provides recommendations for improving AI crawler access.
Uses Google's Gemini 2.0 Flash model (via OpenRouter) for brand mention checks and evaluates Google-Extended bot access from robots.txt.
Uses OpenAI's GPT-4o-mini model (via OpenRouter) to evaluate brand mentions in AI responses for cross-model comparison.
Queries Perplexity's sonar model to check if a brand or domain appears in LLM-generated answers, supporting brand visibility analysis.
MCP server that audits and fixes how AI sees your website. Robots, schema, LLM mentions, Cloudflare AI defaults — audit the problem, generate the fix, re-audit in one loop.
Most websites are accidentally invisible to AI search. Cloudflare's bot-management defaults block GPTBot / ClaudeBot / PerplexityBot. SPAs render an empty <div id="root"> to crawlers that don't run JS. Marketing teams have no idea their brand isn't surfacing in ChatGPT, Claude, or Perplexity answers — until traffic dries up.
ai-visibility-mcp closes the audit-and-fix loop inside a single agent session:
Audit — find what's blocking AI visibility
Fix — generate the artifact that corrects it
Paste — site owner applies the output
Re-audit — verify the fix was picked up
Tool | Purpose | Needs API keys? |
| Per-bot robots.txt + Cloudflare AI-default flag for 22 AI user-agents | No |
| 0-100 composite score with explainable deductions (robots, meta, JSON-LD, sitemap, llms.txt, SPA shell) | No |
| Cross-model brand surfacing (Perplexity sonar + OpenAI gpt-4o-mini + Gemini 2.0 Flash by default) | Yes |
| Parallel ranked audit, max 10 in flight | No |
Tool | Purpose | LLM call? |
| Corrected robots.txt that opens access to AI bots; preserves existing rules; detects Cloudflare | No |
| Schema.org JSON-LD block for any page; auto-detects type (Product/Article/Organization/FAQPage/SoftwareApplication/WebSite); validates required fields | Yes (gpt-4o-mini) |
| spec-compliant llms.txt; crawls homepage + sitemap; graceful fallback to link extraction | Yes (gpt-4o-mini) |
Related MCP server: maxaeo-ai-visibility-mcp
Cloudflare flipped defaults in 2024-2025 to block AI scrapers. Most site owners never updated their config, so AI bots get challenged and bounce.
MCP marketplaces shipped in 2026 (MCP Hive, Smithery, mcp.so, Glama). Every AI agent needs tools that can audit the real web. This is one.
Brand visibility in LLM answers is the new SEO. Nobody has a clean stack for measuring it from a single MCP call.
Requires Python 3.10+ and uv.
git clone https://github.com/bestaiinsider/ai-visibility-mcp
cd ai-visibility-mcp
uv sync
cp .env.example .env # fill in PERPLEXITY_API_KEY / OPENROUTER_API_KEY# stdio transport — Claude Desktop / Claude Code
uv run ai-visibility-mcp
# HTTP transport — remote agents
uv run ai-visibility-mcp --http --port 8000Add to ~/Library/Application Support/Claude/claude_desktop_config.json (Desktop) or ~/.claude.json (CLI):
{
"mcpServers": {
"ai-visibility": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/ai-visibility-mcp", "run", "ai-visibility-mcp"]
}
}
}# Step 1 — audit
> audit_ai_visibility(domain="example.com")
score: 55
warnings:
- "9/22 AI bots disallowed — site largely invisible to AI search"
- "no JSON-LD structured data — LLMs lose entity grounding"
- "no /llms.txt found at root"
# Step 2 — generate fixes
> generate_robots_patch(domain="example.com")
→ new_robots: "User-agent: GPTBot\nAllow: /\n\nUser-agent: ClaudeBot\nAllow: /\n..."
→ diff: unified diff of exactly what changed
→ paste_target: "/robots.txt at site root, replaces existing"
> generate_json_ld(url="https://example.com/")
→ page_type_detected: "Organization"
→ script_tag: '<script type="application/ld+json">{"@context":"https://schema.org","@type":"Organization"...}</script>'
→ paste_target: "inside <head> of the page"
> generate_llms_txt(domain="example.com")
→ content: "# Example Corp\n\n> One-sentence summary...\n\n## Pages\n- [Home](...): ..."
→ paste_target: "/llms.txt"
# Step 3 — site owner pastes the three artifacts
# Step 4 — re-audit
> audit_ai_visibility(domain="example.com")
score: 95 ← was 55> check_ai_bot_access(domain="bandcamp.com")
summary: { total: 22, allowed: 13, disallowed: 9 }
warnings: ["9/22 AI bots disallowed — site largely invisible to AI search"]
blocked: ["GPTBot", "ClaudeBot", "Google-Extended", "Bytespider",
"CCBot", "Meta-ExternalAgent", "FacebookBot", "Amazonbot", "Diffbot"]
> audit_ai_visibility(domain="bandcamp.com")
score: 49
reasons:
-36: 9 AI bots disallowed in robots.txt
-10: no JSON-LD structured data
-5: no /sitemap.xml
> check_llm_mention(brand="Anthropic", query="Who makes the leading foundation AI models?")
share_of_voice: 0.667
by_model:
perplexity/sonar mentioned=true citations=3
openrouter/gpt-4o-mini mentioned=true citations=0
openrouter/gemini-flash mentioned=false citations=0
est_total_cost_usd: 0.00088
daily_spend_usd: 0.00088 / $5.00 capThis server makes outbound HTTP requests to caller-supplied domains and to LLM providers. v0.2 hardening:
SSRF guard. All outbound HTTP refuses loopback, link-local (AWS / GCP / Azure metadata IPs), RFC1918, CGNAT, and IPv6 ULA addresses. Redirects are re-validated.
Daily spend cap. LLM calls are gated by MAX_DAILY_USD (default $5.00), persisted to ~/.cache/ai-visibility-mcp/spend.json. Loop-amplification can't drain your Perplexity / OpenRouter credits.
Per-call cost ceiling. MAX_COST_PER_CALL (default $0.10) plus LLM_MAX_OUTPUT_TOKENS (default 1024) hard-bounds any single tool invocation.
No persistence of user content. Nothing is logged to disk except the daily spend totals.
Env var | Default | Purpose |
| — | Required for Perplexity models in |
| — | Required for OpenAI / Gemini / Claude via OpenRouter |
|
| USD ceiling per tool invocation |
|
| USD ceiling per UTC day, persisted |
|
| Hard cap on output tokens per LLM call |
|
| Override spend ledger location |
uv sync --extra dev
uv run pytest # 40 tests
uv run ruff check . # lintv0.3 — audit + fix loop complete. 7 tools (4 audit + 3 generator), 40/40 tests, SSRF-hardened, spend-capped. Smoke-verified against tealhq.com / bandcamp.com / anthropic.com.
MIT.
Composite AI-visibility audit for a domain.
Combines check_ai_bot_access with homepage scrape: meta robots tags
(incl. noai/noimageai), JSON-LD structured data, sitemap.xml, llms.txt.
Produces a 0-100 score with explainable reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | e.g. `example.com` or `https://example.com` |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the actions: homepage scrape, checking meta robots, JSON-LD, sitemap, llms.txt. It also states output format (0-100 score with reasons). No annotations are provided, but the description gives good insight into behavior.
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 concise: two sentences, front-loaded with purpose, and lists components efficiently. No wasted words.
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?
Given the simple input and presence of an output schema, the description adequately covers the tool's functionality and output. It could mention potential errors or limitations, but overall complete.
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 coverage is 100% with a clear parameter description for 'domain'. The tool description does not add new information beyond what is already in the schema, so 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 clearly states it is a 'Composite AI-visibility audit for a domain', listing specific components and outputs. It distinguishes from sibling tools like 'check_ai_bot_access' (a component) and 'compare_competitors' (different purpose).
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 usage for a comprehensive AI-visibility audit and mentions combining 'check_ai_bot_access', suggesting to use the sibling tool for a simpler check. However, it lacks explicit when-not or usage exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether AI bots can read this site.
Fetches /robots.txt and the root URL. Reports per-bot allow/disallow
plus Cloudflare AI-bot-default warning signals.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | e.g. `example.com` or `https://example.com` |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses fetching two URLs, reporting per-bot allow/disallow and Cloudflare warnings. While it doesn't detail error handling or rate limits, the core read-only behavior is transparent enough for selection.
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?
Two sentences: first states the purpose, second lists actions and outputs. No wasted words. Front-loaded with the core function.
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 simple tool with one parameter and an output schema (not shown), the description sufficiently covers what it does and what it produces. Could be more complete with a note on error scenarios or usage prerequisites, but adequate.
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 coverage is 100% with a clear description for the single 'domain' parameter. The description adds value by explaining that the tool fetches robots.txt and root URL for that domain, providing context beyond the schema's example format.
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 clearly states the verb 'check' and the resource 'AI bot access' for this site. It specifies the actions: fetching /robots.txt and root URL, and reporting per-bot allow/disallow plus Cloudflare signals. This distinguishes it from siblings like audit_ai_visibility (broader audit) and check_llm_mention (mentions).
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 usage contexts (checking AI bot access via robots.txt and root URL) but does not explicitly state when to prefer this tool over siblings like audit_ai_visibility or check_llm_mention. No exclusion criteria or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether brand surfaces in LLM answers to query.
Fans out the same query to multiple LLMs (Perplexity sonar, OpenAI gpt-4o-mini, Gemini 2.0 Flash by default) and reports per-model mention + citations. Cost-capped via MAX_COST_PER_CALL env var.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | brand or product name to look for in answers | |
| query | Yes | the user-style question to ask each model | |
| aliases | No | optional alternate names that should also count as a mention | |
| models | No | optional override, e.g. ["perplexity:sonar", "openrouter:anthropic/claude-3.5-sonnet"] |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses fan-out to multiple LLMs (Perplexity, OpenAI, Gemini), reports per-model mentions and citations, and mentions cost-capping via env var. No annotations provided, so description carries the full burden.
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?
Three concise sentences, front-loaded with purpose, each sentence adds value without fluff.
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?
Given output schema exists, the description adequately covers behavior, model selection, and cost control. Could mention error handling or output format but overall complete for the tool's complexity.
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 descriptions cover all 4 parameters (100% coverage), and the description adds context about default models and cost-capping, enhancing understanding beyond the schema.
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?
Clearly states it checks whether a brand surfaces in LLM answers to a query, specifying the fan-out to multiple LLMs and reporting mentions and citations. This distinguishes it from siblings like audit_ai_visibility and check_ai_bot_access.
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?
Implies usage for brand mention checking but provides no explicit guidance on when to use versus alternatives, no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-by-side AI-visibility audit: your_domain vs competitors.
Runs audit_ai_visibility in parallel for all domains and returns a
ranked comparison (score, blocked bots, JSON-LD presence, llms.txt,
sitemap size, Cloudflare challenge state).
| Name | Required | Description | Default |
|---|---|---|---|
| your_domain | Yes | the domain whose visibility you're evaluating | |
| competitor_domains | Yes | list of competitor domains (at least 1) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states it runs audit_ai_visibility in parallel and returns ranked comparison, but does not mention potential side effects, rate limits, or whether it is read-only. Adequate but could be more explicit.
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 sentences with an embedded bullet list of outputs. Highly efficient, no redundancy, and front-loaded with the core purpose.
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 tool that runs multiple operations, it lacks mention of performance implications or error handling. However, since an output schema exists, the return values are sufficiently described. Nearly complete.
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 coverage is 100%, so parameters are already documented. The description adds context by explaining that domains are used in a parallel audit, which is helpful but not essential beyond the schema.
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 clearly states it performs a side-by-side AI-visibility audit comparing your domain against competitors. It distinguishes from siblings (e.g., audit_ai_visibility for single domain) by explicitly naming the parallel execution and comparison output.
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 usage when a comparative analysis is needed, but does not explicitly exclude use cases like single-domain audits or specify prerequisites. The differentiation from siblings is clear enough.
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. Dates show when Glama detected each change.
v0.2.0audit_ai_visibilitycheck_ai_bot_accesscheck_llm_mentioncompare_competitorsEach tool has a clearly distinct purpose: audit_ai_visibility performs a comprehensive composite audit, check_ai_bot_access focuses solely on robots.txt and bot access, check_llm_mention checks LLM responses for brand mentions, and compare_competitors runs audits across multiple domains. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern: audit_ai_visibility, check_ai_bot_access, check_llm_mention, compare_competitors. The verbs (audit, check, compare) clearly indicate the action, and nouns describe the target.
With 4 tools, the server covers its core domain—AI visibility auditing—without being excessive or insufficient. Each tool contributes a distinct operation: detailed audit, specific check, LLM search, and competitive comparison.
The tool surface is complete for the domain: it includes a comprehensive audit (robots, sitemap, JSON-LD, llms.txt), a specific robots.txt check, LLM mention analysis, and competitor comparison. No obvious missing operations like per-resource checks are needed, as they are covered by the composite audit.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Checks llms.txt, AI crawler access in robots.txt, and sitemap - with a 0-100 AI readiness score.
AEO audit: score any website 0-100 for AI visibility. Checks schema, meta, content, AI crawlers.
Audit your brand's visibility across ChatGPT, Gemini, Claude, Perplexity + 6 more engines.
Scan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bestaiinsider/ai-visibility-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
