SEO + GEO tools in your AI editor: scan as ChatGPT and Google crawlers see it, fix order, llms.txt.
Scored across 4 tools
Each tool addresses a distinct concern: scanning the site, prioritizing fixes, generating an llms.txt file, and checking AI visibility. There is no meaningful overlap between any two tools.
All tools follow the same growthr_ prefix with a clear verb/noun pattern: scan, fix_order, llms_txt, ai_visibility. The naming is uniform and predictable, making the intended action obvious.
Four tools is on the smaller side but well-suited to a focused SEO/GEO audit workflow. Each tool has a clear role and the count feels intentionally scoped rather than incomplete.
The set covers a complete pipeline: audit (scan), prioritize (fix_order), generate output (llms_txt), and measure AI presence (ai_visibility). Minor missing features like link analysis or backlinks exist, but the core workflow is fully functional.
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. Growthr logs the domain and tool name for usage stats.
| 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=true, idempotentHint=true, and destructiveHint=false. The description adds valuable operational context: fetches from a datacenter IP without JavaScript, reads about a dozen public URLs once, and logs the domain and tool name for usage statistics. This goes beyond the annotations without contradicting them.
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 every sentence contributes meaningful detail: retrieval methodology, check categories, output format, resource usage, and logging side effects. It is appropriately detailed for a complex scanning tool, though the check list is dense and could be slightly tightened.
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 of this complexity, the description is remarkably complete. It explains how the crawl is performed, what checks are run, what metrics are returned, how many URLs are read, and what side effects occur. The output schema covers the return structure, so no critical information is missing.
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%, and the schema already clearly defines the 'domain' parameter with an example and the 'no path' restriction. The description reinforces that the domain must be public, but it does not add significant semantic 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 identifies a specific verb and resource: fetch a public domain like search engines and AI crawlers, run 22 weighted checks, and return a 0-100 score with per-check results. This is clear and detailed, but it does not explicitly differentiate itself from sibling tools such as growthr_ai_visibility, growthr_fix_order, or growthr_llms_txt.
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?
No guidance is provided on when to use this tool instead of its siblings. There are no when-to-use, when-not-to-use, or alternative tool references. The description only explains mechanics, leaving the agent to infer selection context.
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.
growthr_ai_visibilitygrowthr_fix_ordergrowthr_llms_txtgrowthr_scanSEO, GEO & AI Visibility — research, write, optimize, publish & monitor content. 121 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.
Open-source AI SEO over MCP: audits, ranks, keywords, backlinks + AI visibility (GEO).
Add one secure layer between your agents and this server.
