AEO Scanner
Server Details
AI visibility for ChatGPT/Perplexity/Claude — triple score (AEO+GEO+Agent) with fix code. Free.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Convrgent/aeo-scanner-mcp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: scan_site for a free quick scan, audit_site for a detailed paid audit, compare_sites for competitive analysis, and fix_site for generating fixes. The descriptions clearly differentiate them, leaving no ambiguity.
All tools follow a verb_noun pattern (scan_site, audit_site, compare_sites, fix_site) with consistent use of lowercase and underscores. The slight plural in compare_sites is justified for comparing two sites, maintaining overall consistency.
With only 4 tools, the server is well-scoped for its domain of AI visibility scanning and fixing. Each tool serves a necessary role without unnecessary bloat or missing core functionality.
The tool set covers the full workflow: quick scan (scan_site), detailed audit (audit_site), competitive benchmarking (compare_sites), and fix generation (fix_site). There are no obvious gaps in this tightly focused domain.
Available Tools
4 toolsaudit_siteARead-onlyInspect
Full AI visibility audit across 77+ checks in 12 categories (4 AEO + 4 GEO + 4 Agent Readiness). Returns detailed per-check scores with specific issues and recommendations, AI Identity Card with mention readiness and detected competitors, and business profile. GEO checks include 3 research-backed citation signals: factual density, answer frontloading, and source citations. Agent Readiness covers emerging agent-discovery standards Cloudflare's isitagentready.com evaluates: RFC 9727 api-catalog, SEP-1649 MCP Server Card, and IETF Content-Signal (draft-romm-aipref). Does NOT generate fix code — pass this response's id as scan_id to fix_site (within 1 hour) to get fixes WITHOUT a re-crawl, or use compare_sites to benchmark against a competitor. Pay per call ($1.00) via x402 — USDC on Base or Solana. Machine payment via signed X-PAYMENT header; see https://www.x402.org/. On payment_required, the response includes the full x402 payload with payTo/amount/asset.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to audit | |
| pages | No | Number of pages to audit (1-10) | |
| categories | No | Filter to specific categories: structured_data, meta_technical, ai_accessibility, content_quality, brand_narrative, citation_readiness, authority_signals, entity_definition, machine_identity, api_discoverability, structured_actions, programmatic_access |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds significant behavioral context: payment mechanism, response format (x402 payload on payment_required), and that no fix code is generated. No contradiction with annotations.
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 well-structured with the core purpose front-loaded in the first sentence. While long, every sentence adds valuable information (scope, categories, integration with other tools, payment). It could be slightly more concise but is not overly verbose.
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 tool's complexity (77+ checks, 12 categories, payment, integration with fix_site and compare_sites), the description covers the audit scope, what is returned (scores, identity card, business profile), and how to proceed for fixes. Without an output schema, it provides adequate guidance on return values.
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 descriptions for all three parameters. The description adds context beyond the schema by explaining the 12 categories in more detail (listing AEO, GEO, Agent Readiness) and describing what GEO and Agent Readiness checks entail. However, it does not add syntax or format details 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 the tool performs a full AI visibility audit across 77+ checks in 12 categories. It specifies the verb 'audit' and resource 'site', and distinguishes from siblings by noting it does not generate fixes (fix_site) or benchmark (compare_sites).
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 explicitly states when to use this tool (for a comprehensive audit) and when not to (for fixes or competitor comparison, directing to fix_site and compare_sites). It also provides context on payment via x402 and the need for a signed header.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_sitesARead-onlyInspect
Competitive gap analysis — scans two sites concurrently, shows side-by-side scores, category-by-category winners, competitive gaps (checks where the competitor scored 20+ higher), and generated overtake fix code with projected scores after closing gaps. Use this when the user wants to benchmark against a competitor or when scan_site detects competitors in the AI Identity Card. Pay per call ($3.00) via x402 — USDC on Base or Solana. On payment_required, the response includes the full x402 payload with payTo/amount/asset.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Your site URL | |
| pages | No | Number of pages to scan per site (1-5) | |
| competitorUrl | Yes | Competitor site URL to benchmark against |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses payment details ($3.00 via x402), concurrent scanning behavior, and specific outputs (fix code, projected scores). No contradictions with annotations.
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 a single paragraph that packs essential information without excess. It is front-loaded with the main purpose and structured logically. Could be slightly more structured (e.g., bullet points) but remains effective.
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 no output schema, the description adequately details the key outputs (scores, winners, gaps, fix code, projected scores) and payment behavior. It covers the major aspects needed for an AI agent to use the tool, though error handling or rate limits are not mentioned.
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 clear parameter descriptions. The description does not add additional meaning beyond the schema, providing no new insights into parameter usage or formatting. Baseline of 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 identifies the tool as a competitive gap analysis that scans two sites concurrently and provides side-by-side scores, category winners, gaps, and generated fix code. It distinctly distinguishes itself from sibling tools like scan_site (single site) and audit_site.
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?
Explicitly states when to use: benchmarking against a competitor or when scan_site detects competitors. Provides payment context. Lacks explicit exclusions for when not to use, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fix_siteAInspect
Generate complete fix code for all AI visibility issues across AEO, GEO, and Agent Readiness. Returns working code you can apply directly — schema generation, robots.txt, sitemap, llms.txt, meta tags, structured data, citation signals, entity markup. Also returns two-tier score projections: quick wins (critical + high fixes only) and full implementation ceiling (all fixes). TIP: pass scan_id from a fresh audit_site result (kept 1 hour) to skip the re-crawl — instant response, same price. Content recommendations include research citations. Run scan_site first to see which issues exist. Pay per call ($5.00) via x402 — USDC on Base or Solana. On payment_required, the response includes the full x402 payload with payTo/amount/asset.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full URL to generate fixes for (required unless scan_id is given) | |
| pages | No | Number of pages to analyze (1-10); ignored when scan_id is used | |
| format | No | Output format: generic or claude_code (optimized for Claude Code) | generic |
| scan_id | No | id from a recent audit_site response — reuses that crawl (1h TTL), instant response |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint: true. The description adds important behavioral details: it costs $5.00 per call via x402, requires payment on payment_required, returns working code (not directly applying changes), and includes score projections and research citations. It does not hide any side effects or costs, providing transparency beyond annotations.
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 long but front-loaded with the main purpose. Every sentence adds value (usage tip, pricing, output details). However, it could be slightly more concise by integrating pricing into a standard metadata section. Still, it is well-structured and not overly verbose.
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 tool complexity (multiple outputs, pricing, integration with scan_site/audit_site, no output schema), the description covers key aspects: what it generates, how to optimize with scan_id, prerequisites, cost, and payment process. It leaves little ambiguity for an agent to decide when and how to invoke it.
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 baseline is 3. The description enriches parameters: explains that scan_id reuses a crawl (1h TTL), pages is ignored when scan_id is given, and format options (generic vs claude_code). It also mentions the x402 payment flow. This adds meaning 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 the tool generates complete fix code for AI visibility issues across AEO, GEO, and Agent Readiness. It specifies the outputs (code, score projections) and distinguishes itself from sibling tools like scan_site (for seeing issues) and audit_site (for deeper audit). The verb 'Generate' and resource 'fix code' are specific.
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 advises running scan_site first to see which issues exist, and explains the scan_id tip to skip re-crawl using a recent audit_site result. It provides context for when to use the tool but does not explicitly state when not to use it or fully differentiate from compare_sites. Still, the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_siteARead-onlyInspect
Quick AI visibility scan. Returns three scores: AEO Score (0-100, AI search engine findability), GEO Score (0-100, AI citation readiness), and Agent Readiness Score (0-100, AI agent interaction capability). Also returns AI Identity Card with mention readiness (0-100, predicts how likely AI will mention the brand), detected competitors, business profile (commerce/saas/media/general), and top 5 issues. 77+ checks across 12 categories. Free — no API key needed. Does NOT return per-check details or fix code — use audit_site for full breakdown, fix_site for generated fixes, compare_sites to benchmark against a competitor.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to scan (e.g. https://example.com) | |
| pages | No | Number of pages to scan (1-5) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that it is free and requires no API key, which is useful behavioral context beyond annotations. No contradictions.
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?
Description is a single paragraph, front-loaded with key information about what the tool does and returns. Every sentence adds value without fluff. Very concise.
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?
Despite no output schema, the description thoroughly explains the return values (three scores, AI Identity Card, mention readiness, detected competitors, business profile, top 5 issues) and limitations (no per-check details). 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 description coverage is 100% with both parameters described. Description does not add extra meaning beyond the schema for parameters, 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?
Description clearly states it is a 'Quick AI visibility scan' that returns three scores and an AI Identity Card. It distinguishes from siblings by explicitly naming what it does not return and directing to audit_site, fix_site, and compare_sites.
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?
Description explicitly says 'Does NOT return per-check details or fix code — use audit_site for full breakdown, fix_site for generated fixes, compare_sites to benchmark against a competitor.' This provides clear when-to-use and when-not-to-use guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!