AI visibility for ChatGPT/Perplexity/Claude — triple score (AEO+GEO+Agent) with fix code. Free.
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.
Average 4.5/5 across 4 of 4 tools scored.
Each tool has a distinct purpose: quick free scan, full paid audit, fix generation, and competitive comparison. No overlap or ambiguity.
All tools use verb_noun pattern (scan_site, audit_site, fix_site, compare_sites) with clear, descriptive verbs and consistent formatting.
4 tools is a compact yet complete set for the domain, covering the essential workflows without bloat.
Covers scanning, detailed auditing, fix generation, and competitive comparison. Minor gaps like history or update/delete tools but core workflows are fully supported.
audit_siteAFull 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate read-only behavior. It adds valuable context about payment ($1.00 via x402), the x402 payload on payment_required, and the one-hour window for using the id with fix_site. 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 well-structured, starting with the core purpose and then detailing categories, checks, payment, and sibling tool relations. While it is longer than necessary, every sentence adds value and there is no 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?
Despite lacking an output schema, the description thoroughly explains what the tool returns (per-check scores, AI Identity Card, business profile) and the payment flow. It covers all essential aspects for correct invocation and interpretation, making it highly 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 baseline is 3. The description adds context beyond the schema by explaining the audit spans 12 categories (mapping to the categories parameter options) and details checks like GEO signals and Agent Readiness. This helps the agent understand the scope of each parameter.
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 with 77+ checks in 12 categories, distinguishing it from sibling tools like fix_site (which generates fixes) and compare_sites (benchmarking). It also explicitly says what it does NOT do (generate fix code), leaving no ambiguity.
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 provides explicit guidance on when to use this tool versus alternatives: it instructs to pass the response id to fix_site for fixes and mentions compare_sites for benchmarking. It also notes the payment requirement and x402 protocol, making usage conditions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_sitesACompetitive 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. Description adds critical behavioral context: pay-per-call ($3.00 via x402 on Base or Solana), concurrent scanning, and payment_required response handling. 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?
Concise and well-structured: function first, then usage context, then payment details. Every sentence adds value, no 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 the complexity (competitive analysis with payment), the description covers output (scores, winners, gaps, fix code, projected scores) and the payment flow. No output schema needed as description covers return value sufficiently.
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 url, pages, competitorUrl. The tool description adds no significant meaning beyond the schema; it merely restates that url and competitorUrl are site URLs. 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 'Competitive gap analysis — scans two sites concurrently, shows side-by-side scores...' which is a specific verb+resource. It distinguishes from sibling tools like scan_site (single site scan) and audit_site (single site audit).
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: 'Use this when the user wants to benchmark against a competitor or when scan_site detects competitors in the AI Identity Card.' Also provides payment handling guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fix_siteAInspectGenerate 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide openWorldHint: true, and the description adds behavioral context: payment per call ($5.00), x402 payload on payment_required, scan caching (1h TTL), and that returned code is 'working code you can apply directly.' 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 front-loaded with the core purpose, then provides a TIP and additional details. It is somewhat lengthy but every sentence adds value, such as payment flow and content recommendations. Could be slightly more streamlined.
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 4 parameters with no output schema, the description covers returns (two-tier score projections, working code), payment handling, and integration with sibling tools. It does not detail error responses beyond payment, but overall is adequately 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 baseline 3. The description adds significant meaning: scan_id is described as reusing a crawl with 1h TTL, pages is ignored with scan_id, and format is 'optimized for Claude Code' for claude_code enum. This improves over schema alone.
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's purpose: 'Generate complete fix code for all AI visibility issues across AEO, GEO, and Agent Readiness.' It lists specific outputs (schema generation, robots.txt, etc.) and distinguishes itself from siblings by referencing scan_id from audit_site and suggesting scan_site first.
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 provides a TIP on using scan_id for instant response, advises running scan_site first, and explains the payment flow with x402. It gives clear context but could more explicitly contrast with sibling tools to say when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_siteAQuick 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds context: free, no API key needed, outputs specific scores and an AI Identity Card, and performs 77+ checks across 12 categories. It does not contradict annotations and provides extra behavioral details beyond what annotations offer.
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 front-loads the main purpose, then details outputs, exclusions, and alternatives. Every sentence contributes value, though it could be slightly more concise by removing the '77+ checks' detail, which is additional but not critical.
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 lack of an output schema, the description fully explains the return values: three scores with ranges, AI Identity Card components, and top 5 issues. It also mentions the scope (77+ checks, 12 categories) and what is excluded. With annotations providing safety context, the description is complete for an agent to understand the tool's purpose and output.
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 both url and pages described. The description reiterates that pages controls the number of pages to scan but adds no further semantic meaning beyond the schema. The free and no-API-key information is contextual but not parameter-specific.
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 'Quick AI visibility scan' and returns specific scores (AEO, GEO, Agent Readiness) and an AI Identity Card. It explicitly distinguishes itself from sibling tools by stating what it does NOT return and recommending alternatives like 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?
Explicitly states when to use ('Quick AI visibility scan'), that it's free and requires no API key, and provides clear exclusions: '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.'
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.
No comments yet. Be the first to start the discussion!