alice
Server Details
Audit any site's AI visibility from your assistant: crawler access, rendering, and schema.
- Status
- Healthy
- Uptime
- 100.0% over 38 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
Scored across 2 tools
The two tools serve clearly distinct purposes: one audits a single site and includes live AI mention checks, while the other benchmarks 2-4 sites on technical AI readability only. The descriptions explicitly state the comparison tool does not test live AI mentions, reducing overlap further.
Both names follow the same verb_noun pattern with snake_case: check_ai_visibility and compare_ai_visibility. The shared resource/action phrasing makes the relationship predictable and readable.
Two tools is slightly thin for a general server, but the purpose is narrow and each tool covers a distinct workflow: single-site audit and multi-site benchmarking. The count is reasonable for the scoped domain, though a third operation such as retrieving detailed report data might round it out.
The surface covers the core single-site audit and competitive comparison workflows. Minor gaps remain around retrieving or storing detailed live-check results beyond the provided report link, and there is no explicit fix-application or historical tracking operation.
Available Tools
2 toolscheck_ai_visibilityCheck AI visibilityARead-onlyInspect
Check whether AI names a website when buyers ask, and whether AI can read it. Starts a live check of one brand-name question and one buyer question on Google AI Overviews, ChatGPT, Claude and Gemini (results fill in on the report link within about a minute), and returns a 0-100 AI readability score: which AI crawlers the site allows or blocks, whether content is server-rendered, structured-data coverage, and the highest-impact fixes. Use when someone asks whether ChatGPT, Claude, Gemini or Google AI mention or cite their site, how their site appears to AI, whether AI can read or find it, or asks for an SEO or AI visibility audit of a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Site or page URL. Scheme optional; https:// is assumed. | |
| full | No | Include classic SEO, crawlability and analytics-tag sections. Default returns AI visibility only. | |
| locale | No | Saved-report page language: en, zh-TW or ja. Independent of the scan market. | en |
| country | No | Scan market country code. Defaults to the page language’s market: us, tw or jp. | |
| language | No | AI question/probe language code, e.g. en, zh-tw or ja. Defaults to the selected country’s language. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| gated | No | |
| score | Yes | |
| checks | Yes | |
| ai_check | No | The live brand-name / buyer-question check across the AI engines. status "checking" means the engines are still answering; the report_url shows the settled result. |
| next_step | Yes | |
| report_url | No | |
| scanned_at | No | |
| top_actions | Yes | |
| score_breakdown | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, openWorld, non-destructive), and the description adds behavior the agent cannot get elsewhere: a ‘live’ asynchronous check whose results ‘fill in on the report link within about a minute’. It also enumerates what the returned score is built from (crawler allow/block rules, server-rendering, structured-data coverage, highest-impact fixes), which nothing in the structured fields discloses.
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 dense sentences, front-loaded with the core question and followed by mechanism and triggers; nothing repeats the name or title. The second sentence is long and clause-heavy, but every clause (platforms, timing, score components, trigger phrases) carries information.
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?
An output schema exists, so return formatting needn't be explained, yet the description still summarizes the score's composition and the async timing, which is exactly what an agent needs for a slow, open-world check. The only gap is silence on the optional full/locale/country/language knobs, which the schema covers adequately.
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 explains url, full, locale, country and language. The description adds no parameter-level detail — it does not mention the full/SEO toggle, locale, country or language at all — so 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 ('check whether AI names a website... and whether AI can read it'), then concretizes it: one brand question + one buyer question across Google AI Overviews, ChatGPT, Claude and Gemini plus a 0-100 readability score. The single-URL scope also implicitly separates it from the sibling compare_ai_visibility, so an agent can route on it 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?
Gives an explicit trigger list ('Use when someone asks whether ChatGPT, Claude, Gemini or Google AI mention or cite their site... or asks for an SEO or AI visibility audit of a URL'), which is strong positive routing. It never names compare_ai_visibility or states when not to use this tool, so the alternative-selection clause is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_ai_visibilityCompare AI visibilityARead-onlyInspect
Compare how visible several websites are to AI answer engines, side by side. Scans 2-4 URLs and ranks them by AI visibility score, showing which blocks AI crawlers, which is server-rendered, and which has answer-ready structured data. Use when someone wants to benchmark their site against competitors, or asks why a competitor gets recommended by AI assistants and they do not. This compares technical readability only; it does not test live AI mentions.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Two to four site URLs. Put the user’s own site first; results are returned ranked by score. | |
| locale | No | Saved-report page language: en, zh-TW or ja. Independent of the scan market. | en |
| country | No | Scan market country code. Defaults to the page language’s market: us, tw or jp. | |
| language | No | AI question/probe language code, e.g. en, zh-tw or ja. Defaults to the selected country’s language. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| gated | No | |
| next_step | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, non-destructive and openWorld, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the 2-4 URL scan scope, the ranking behavior, the three technical dimensions inspected, and a clear limitation (technical readability only, no live AI mention testing).
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?
Four sentences, each earning its place: purpose, output content, when-to-use triggers, and scope boundary. Front-loaded with the core purpose and no redundant filler.
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?
An output schema exists and all four parameters are fully described in the schema, so the description need not cover return values. It covers purpose, usage and scope limits well; the only minor gap is that locale/country/language parameters are never mentioned, though the schema handles them adequately.
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 urls, locale, country and language thoroughly, including the 'own site first' convention and the locale/market independence. The description adds only the 'scans 2-4 URLs' restatement, 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 (Compare) plus resource (AI visibility of websites), names the plural scope ('several websites... side by side'), and enumerates what it reports (crawler blocking, server-rendering, structured data). This implicitly and clearly separates it from the singular check_ai_visibility sibling.
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 two concrete triggers ('benchmark their site against competitors', 'asks why a competitor gets recommended') and an explicit scope exclusion ('does not test live AI mentions'). It does not, however, name check_ai_visibility as the alternative for single-site checks, so routing to the sibling is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
check_ai_visibility3 fields changed- added
Input schema / properties / countryAdded value: +{ + "description": "Scan market country code. Defaults to the page language’s market: us, tw or jp.", + "enum": [ + "af", + "al", + "dz", + "ad", + "ao", + "ag", + "ar", + "am", + "au", + "at", + "az", + "bs", + "bh", + "bd", + "bb", + "be", + "bz", + "bj", + "bt", + "bo", + "ba", + "bw", + "br", + "bn", + "bg", + "bf", + "bi", + "kh", + "cm", + "ca", + "cv", + "cf", + "td", + "cl", + "cn", + "co", + "km", + "cg", + "cd", + "cr", + "ci", + "hr", + "cy", + "cz", + "dk", + "dj", + "dm", + "do", + "ec", + "eg", + "sv", + "gq", + "er", + "ee", + "sz", + "et", + "fj", + "fi", + "fr", + "ga", + "gm", + "ge", + "de", + "gh", + "gr", + "gd", + "gt", + "gn", + "gw", + "gy", + "ht", + "hn", + "hk", + "hu", + "is", + "in", + "id", + "iq", + "ie", + "il", + "it", + "jm", + "jp", + "jo", + "kz", + "ke", + "ki", + "kw", + "kg", + "la", + "lv", + "lb", + "ls", + "lr", + "ly", + "li", + "lt", + "lu", + "mg", + "mw", + "my", + "mv", + "ml", + "mt", + "mh", + "mr", + "mu", + "mx", + "fm", + "md", + "mc", + "mn", + "me", + "ma", + "mz", + "mm", + "na", + "nr", + "np", + "nl", + "nz", + "ni", + "ne", + "ng", + "mk", + "no", + "om", + "pk", + "pw", + "ps", + "pa", + "pg", + "py", + "pe", + "ph", + "pl", + "pt", + "qa", + "ro", + "rw", + "kn", + "lc", + "vc", + "ws", + "sm", + "st", + "sa", + "sn", + "rs", + "sc", + "sl", + "sg", + "sk", + "si", + "sb", + "so", + "za", + "kr", + "es", + "lk", + "sr", + "se", + "ch", + "tw", + "tj", + "tz", + "th", + "tl", + "tg", + "to", + "tt", + "tn", + "tr", + "tm", + "tv", + "ug", + "ua", + "ae", + "gb", + "us", + "uy", + "uz", + "vu", + "va", + "ve", + "vn", + "ye", + "zm", + "zw" + ], + "type": "string" +} - added
Input schema / properties / languageAdded value: +{ + "description": "AI question/probe language code, e.g. en, zh-tw or ja. Defaults to the selected country’s language.", + "enum": [ + "ps", + "sq", + "ar", + "ca", + "pt", + "en", + "es", + "hy", + "de", + "az", + "bn", + "nl", + "fr", + "dz", + "bs", + "pt-br", + "ms", + "bg", + "km", + "zh-cn", + "hr", + "el", + "cs", + "da", + "ti", + "et", + "am", + "fi", + "ka", + "zh-tw", + "hu", + "is", + "id", + "iw", + "it", + "ja", + "kk", + "ky", + "lo", + "lv", + "lt", + "dv", + "mt", + "ro", + "mn", + "sr", + "my", + "ne", + "mk", + "no", + "ur", + "pl", + "rw", + "sk", + "sl", + "so", + "ko", + "si", + "sv", + "tg", + "sw", + "th", + "tr", + "tk", + "uk", + "uz", + "vi" + ], + "type": "string" +} - added
Input schema / properties / localeAdded value: +{ + "default": "en", + "description": "Saved-report page language: en, zh-TW or ja. Independent of the scan market.", + "enum": [ + "en", + "zh-TW", + "ja" + ], + "type": "string" +}
- Changed
compare_ai_visibility3 fields changed- added
Input schema / properties / countryAdded value: +{ + "description": "Scan market country code. Defaults to the page language’s market: us, tw or jp.", + "enum": [ + "af", + "al", + "dz", + "ad", + "ao", + "ag", + "ar", + "am", + "au", + "at", + "az", + "bs", + "bh", + "bd", + "bb", + "be", + "bz", + "bj", + "bt", + "bo", + "ba", + "bw", + "br", + "bn", + "bg", + "bf", + "bi", + "kh", + "cm", + "ca", + "cv", + "cf", + "td", + "cl", + "cn", + "co", + "km", + "cg", + "cd", + "cr", + "ci", + "hr", + "cy", + "cz", + "dk", + "dj", + "dm", + "do", + "ec", + "eg", + "sv", + "gq", + "er", + "ee", + "sz", + "et", + "fj", + "fi", + "fr", + "ga", + "gm", + "ge", + "de", + "gh", + "gr", + "gd", + "gt", + "gn", + "gw", + "gy", + "ht", + "hn", + "hk", + "hu", + "is", + "in", + "id", + "iq", + "ie", + "il", + "it", + "jm", + "jp", + "jo", + "kz", + "ke", + "ki", + "kw", + "kg", + "la", + "lv", + "lb", + "ls", + "lr", + "ly", + "li", + "lt", + "lu", + "mg", + "mw", + "my", + "mv", + "ml", + "mt", + "mh", + "mr", + "mu", + "mx", + "fm", + "md", + "mc", + "mn", + "me", + "ma", + "mz", + "mm", + "na", + "nr", + "np", + "nl", + "nz", + "ni", + "ne", + "ng", + "mk", + "no", + "om", + "pk", + "pw", + "ps", + "pa", + "pg", + "py", + "pe", + "ph", + "pl", + "pt", + "qa", + "ro", + "rw", + "kn", + "lc", + "vc", + "ws", + "sm", + "st", + "sa", + "sn", + "rs", + "sc", + "sl", + "sg", + "sk", + "si", + "sb", + "so", + "za", + "kr", + "es", + "lk", + "sr", + "se", + "ch", + "tw", + "tj", + "tz", + "th", + "tl", + "tg", + "to", + "tt", + "tn", + "tr", + "tm", + "tv", + "ug", + "ua", + "ae", + "gb", + "us", + "uy", + "uz", + "vu", + "va", + "ve", + "vn", + "ye", + "zm", + "zw" + ], + "type": "string" +} - added
Input schema / properties / languageAdded value: +{ + "description": "AI question/probe language code, e.g. en, zh-tw or ja. Defaults to the selected country’s language.", + "enum": [ + "ps", + "sq", + "ar", + "ca", + "pt", + "en", + "es", + "hy", + "de", + "az", + "bn", + "nl", + "fr", + "dz", + "bs", + "pt-br", + "ms", + "bg", + "km", + "zh-cn", + "hr", + "el", + "cs", + "da", + "ti", + "et", + "am", + "fi", + "ka", + "zh-tw", + "hu", + "is", + "id", + "iw", + "it", + "ja", + "kk", + "ky", + "lo", + "lv", + "lt", + "dv", + "mt", + "ro", + "mn", + "sr", + "my", + "ne", + "mk", + "no", + "ur", + "pl", + "rw", + "sk", + "sl", + "so", + "ko", + "si", + "sv", + "tg", + "sw", + "th", + "tr", + "tk", + "uk", + "uz", + "vi" + ], + "type": "string" +} - added
Input schema / properties / localeAdded value: +{ + "default": "en", + "description": "Saved-report page language: en, zh-TW or ja. Independent of the scan market.", + "enum": [ + "en", + "zh-TW", + "ja" + ], + "type": "string" +}
2 tool updates
- First observed
check_ai_visibility - First observed
compare_ai_visibility
Related MCP Connectors
Audit any website for AI visibility: graded report, findings with fixes, AI crawler access check.
Audit how AI assistants and search engines find, understand and recommend a website.
Audit websites for SEO from your AI assistant: scores, issues with fixes, Google indexability
AEO audit: score any website 0-100 for AI visibility. Checks schema, meta, content, AI crawlers.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables AI assistants to audit a website's AI visibility by checking crawler access, identity files, and page signals, and running a full scored audit across ChatGPT, Claude, Gemini, and Perplexity.1090 npmMIT
- AlicenseNot gradedqualityCmaintenanceEvaluates any website's AI visibility with 15 checks across crawlability, structure, content, and connectivity, and provides actionable fixes.8 npmMIT
- FlicenseNot gradedqualityCmaintenanceAudits any website for SEO issues, providing scored health checks, schema validation, and performance analysis through AI assistants.-
- AlicenseAqualityCmaintenanceEnables AI assistants to check how discoverable a website is to AI search engines and assistants by inspecting signals like crawler access, llms.txt, structured data, and on-page metadata, and returning a 0-100 visibility score.1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.