SEO + GEO tools in your AI editor: scan as ChatGPT and Google crawlers see it, fix order, llms.txt.
Run one buyer-shaped prompt through Gemini with Google Search grounding (a real, cited web search, the same mechanism behind Google AI Overviews) and report where the brand lands on the five-rung ladder: absent, cited (a page of the brand's site is a source), mentioned (named in the text), recommended (on the shortlist), or recommended against. Also returns the other names on the shortlist and the source domains the answer was built from. One prompt per call; limited to a few calls per day per user because grounded requests are billed per query.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand name to look for, e.g. 'Growthr' | |
| domain | No | Optional brand domain, e.g. growthr.com, to detect citations | |
| prompt | Yes | The question a buyer would ask, e.g. 'best corporate event photographer in New York' |
| Name | Required | Description |
|---|---|---|
| rung | Yes | |
| cited | No | |
| engine | Yes | |
| against | No | |
| sources | Yes | Source domains the answer was built from |
| mentioned | No | |
| shortlist | Yes | Providers the answer put forward |
| recommended | No | |
| shortlistSource | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description goes further by revealing the external API mechanism (Gemini with Google Search grounding, 'a real, cited web search'), the cost model ('billed per query'), and the rate limit ('a few calls per day per user'), which are critical behavioral traits not captured in the 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 three-sentence description is dense but well-structured: the first sentence front-loads the core purpose, the second details the output contract, and the third covers constraints. It is slightly long with embedded clauses but remains free of redundancy and 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?
Given the tool's complexity—external API call, multiple output categories, cost and rate limits—the description covers the mechanism, the five-rung output ladder, additional returned data (shortlist names, source domains), and constraints, leaving no critical gap for an agent to call it correctly.
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 input schema covers all three parameters (brand, domain, prompt) with descriptions and concrete examples, achieving 100% schema description coverage, so the baseline holds. The description adds minor context ('buyer-shaped prompt' clarifies the prompt parameter) but does not substantially expand parameter meaning beyond what the schema already provides.
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 action ('Run one buyer-shaped prompt through Gemini with Google Search grounding') and a specific report output ('where the brand lands on the five-rung ladder'), enumerating all five rungs (absent, cited, mentioned, recommended, recommended against). It also clearly differentiates this from sibling tools (growthr_fix_order, growthr_llms_txt, growthr_scan) by focusing on AI answer visibility rather than order fixing, LLM.txt files, or scanning.
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 usage constraints ('One prompt per call', 'limited to a few calls per day per user', 'billed per query') that tell the agent when to be economical, and the phrase 'buyer-shaped prompt' clarifies the intent of the input. However, it does not explicitly state when to prefer this tool over a sibling or when not to use it (e.g., if a simple scan suffices).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the scan and sort every failed check into buckets: blockers (fix before anything else, they hide everything downstream), this afternoon (metadata, llms.txt, trust pages, on-page), needs a sprint (schema, markdown negotiation, speed), and the off-site work no scan can measure (reviews, directories, third-party mentions), which is what decides whether AI engines recommend a business.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Public domain, e.g. example.com |
| Name | Required | Description |
|---|---|---|
| other | No | |
| score | Yes | |
| domain | Yes | |
| sprint | Yes | |
| blockers | Yes | Check ids to fix before anything else |
| afternoon | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Run the scan,' implying a read-only action, and annotations confirm read-only and non-destructive behavior, but it does not call out side effects or limits beyond what annotations already state.
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 one long sentence with stylized bucket names and explanatory asides; it is informative but somewhat wordy, and the front-loaded purpose is somewhat buried by the extended categorization.
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 output buckets and their significance, and with the output schema present it gives enough context for an agent to know what to expect from a call.
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?
Only one parameter, domain, is documented in the schema with a clear example. The description adds no further detail about the parameter, so it relies on 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 specifies the tool's purpose: it runs a scan and sorts failed checks into prioritized buckets, with category examples. This distinguishes it from sibling scan/visibility tools by emphasizing prioritization.
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?
It describes what the tool does but does not explicitly state when to choose it over the sibling scan or visibility tools; no direct when-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a site's homepage, sitemap (or homepage links), and up to twelve pages, then draft an llms.txt in the llmstxt.org format: H1 name, blockquote summary, grouped page list with one-line descriptions, contact, profiles, links. The 'When to use' section is left as a marked placeholder on purpose; it is a judgment about the business that no crawler can write. Returns the draft plus notes on anything skipped.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Public domain, e.g. example.com |
| Name | Required | Description |
|---|---|---|
| notes | No | |
| pages | No | Pages read |
| domain | Yes | |
| llmsTxt | Yes | The draft, llmstxt.org format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool performs network reads (homepage, sitemap, pages) and returns a draft plus notes on skipped items. It also explains the intentional placeholder in the output. These details go beyond the annotations (readOnlyHint, idempotentHint) to describe behavior completely.
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 and well-structured: it front-loads the action, then explains the output format, the placeholder, and the return value. No redundant sentences; all information is necessary and presented logically.
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 provides enough context for an agent to understand the full workflow: what is read, what is produced, the format details, and the inclusion of a placeholder. It also notes the return of notes on skipped items. The description is 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?
The schema already describes the 'domain' parameter with 100% coverage (e.g., example.com). The description does not add significant additional semantic value beyond what the schema provides, so it matches the baseline for full coverage.
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 function: it reads a site's homepage, sitemap or links, and up to twelve pages, then drafts an llms.txt file. The verb 'draft' and the resource 'llms.txt for a site' are specific, and the description distinguishes it from sibling tools by focusing on llms.txt generation.
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 implicitly indicates when to use the tool (when an llms.txt draft is needed) but does not explicitly contrast it with sibling tools like growthr_scan. The purpose is clear, yet explicit selection guidance would improve this dimension slightly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public domain the way search engines and AI crawlers do (ChatGPT's GPTBot, Claude's ClaudeBot, and the fetchers behind Perplexity and Google AI Overviews: from a datacenter IP, no JavaScript) and run 22 weighted checks: reachability as a browser, GPTBot, and ClaudeBot; server-rendered content; metadata; strict JSON-LD and Organization schema; robots.txt access for AI crawlers; llms.txt and an in-page link to it; sitemap; honest 404s; markdown negotiation; trust pages; speed; and on-page SEO (title, description, single h1, viewport, alt text, favicon). Returns a 0-100 score and every check with pass/fail, what was found, and a fix hint. Reads about a dozen public URLs once; nothing is stored.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Public domain, e.g. example.com (no path) |
| Name | Required | Description |
|---|---|---|
| score | Yes | 0-100 |
| checks | Yes | |
| domain | Yes | |
| throttledCount | No | Requests the site answered with HTTP 429 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the tool is known to be safe and idempotent. The description adds valuable behavioral context: it fetches from a datacenter IP, no JavaScript, reads about a dozen URLs once, and stores nothing. This goes beyond annotations by detailing the crawling behavior and network footprint.
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 dense paragraph that front-loads the main purpose and lists checks. While long, every clause adds useful detail (crawler types, check categories, output, storage policy). It is structured logically from what it does, to what it returns, to side effects. No fluff, though it could be split into shorter sentences for readability.
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 tool is complex with 22 checks and a structured output. The description enumerates the check categories, explains the crawl methodology, clarifies the output format (score and per-check results), and states the side effects (reads ~12 URLs once, nothing stored). Since an output schema exists, return value details are covered there. The description provides a complete mental model for an agent to decide and invoke the tool correctly.
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 the domain parameter is already documented. The description reinforces its meaning ('Public domain, e.g. example.com (no path)') by explaining the domain is what gets fetched. It adds the nuance that the domain is used as the entry point for the crawl, though the schema already covers the format. The baseline of 3 is exceeded because the description ties the parameter to the tool's core behavior.
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: it fetches a public domain as search engines and AI crawlers do, runs 22 specific checks, and returns a 0-100 score with per-check results. The verb 'Fetch' and resource 'public domain' are specific, and the tool is distinct from siblings like growthr_fix_order (which likely fixes) and growthr_llms_txt (which focuses on llms.txt), making it easy for an agent to identify when to use this scan.
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 context (scan a site for SEO/AI readability) and lists the checks, but does not explicitly state when to use this tool versus alternatives like growthr_ai_visibility. However, the clear scope and the sibling names provide implicit differentiation. A more explicit 'when not to use' would elevate this.
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.
growthr_ai_visibilitygrowthr_fix_ordergrowthr_llms_txtgrowthr_scanClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
SEO, GEO & AI Visibility — research, write, optimize, publish & monitor content. 122 tools.
Run SEO + AI-visibility (GEO) audits from Claude, Cursor & other AI clients.
AI visibility for ChatGPT/Perplexity/Claude — triple score (AEO+GEO+Agent) with fix code. Free.
Free SEO, GEO, and AEO audits: analyze any page or domain, AI-crawler access, agent readiness.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct deliverable: technical audit, AI visibility check, llms.txt draft, and fix prioritization. The outputs and workflows described are separate enough that an agent should not confuse one tool for another.
All tools share the growthr_ prefix and snake_case, which provides some consistency, but the post-prefix naming is mixed: 'scan' and 'fix_order' are verb-led while 'ai_visibility' and 'llms_txt' are noun phrases. There is no consistent verb_noun pattern across the set.
Four tools is a well-scoped size for an SEO/GEO audit server, and each tool has a distinct, non-redundant role. This is within the ideal range and does not feel either sparse or bloated.
The tool set covers the core lifecycle of auditing, measuring AI visibility, generating llms.txt, and prioritizing fixes. Minor gaps exist—such as no explicit historical tracking or content-optimization tool—but the main workflow is usable without dead ends.
