Free, no signup: AI crawler check, llms.txt validator, ChatGPT/Perplexity/Gemini citation check.
Scored across 3 tools
The three tools target clearly different activities: AI citation checking, crawler/readiness auditing, and llms.txt validation. There is minor overlap since check_ai_crawler_readiness also reports whether llms.txt exists while validate_llms_txt examines it in depth, but the descriptions make the boundary (shallow presence vs. content validation) reasonably clear.
All names use snake_case with a verb_noun structure (check_ai_citations, check_ai_crawler_readiness, validate_llms_txt). The only deviation is the switch between 'check_' and 'validate_', which is minor and still predictable.
Three tools is at the thin end for a suite branded as AI SEO tools, even a free one. Each tool is meaningful and non-redundant, but the surface feels narrow rather than well-scoped.
The set covers the three main AI-SEO audit angles (citations, crawler access, llms.txt) but is read-only: there is no way to generate or fix an llms.txt, inspect robots.txt directly, or produce any remediation output. Agents can audit but cannot complete a fix workflow, leaving notable gaps.
Check whether ChatGPT, Perplexity and Gemini cite a domain when asked the given questions. Send 1 to 5 realistic buyer questions (each at least 5 characters). Returns, per AI, how many questions cited the domain. Each check calls paid AI APIs, so the limit is 5 checks per 30 minutes per IP.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The domain to look for in AI answers, e.g. example.com. | |
| queries | Yes | 1 to 5 buyer questions to ask each AI, e.g. "best crm for dentists". Each at least 5 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses that each check calls paid external AI APIs, imposes a rate limit (5 per 30 minutes per IP), and returns per-AI citation counts. Cost and throttling context like this is exactly what annotations cannot convey.
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?
Three sentences, front-loaded with the purpose, then input constraints, then return shape and cost limit. Nothing is redundant or padding.
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?
With no output schema, the description still explains the return value (per-AI count of questions that cited the domain), plus inputs, limits and cost. Nothing an agent needs to call this correctly 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%, so domain and queries are already fully documented. The description restates the 1-5 question bound and the 5-character minimum plus the 'realistic buyer question' framing, which adds only marginal 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 names a specific verb and resource with scope: it checks whether ChatGPT, Perplexity and Gemini cite a given domain for supplied questions. That is concrete enough to distinguish it from check_ai_crawler_readiness and validate_llms_txt by subject matter, though neither sibling is named explicitly.
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 tells the agent what to send ('1 to 5 realistic buyer questions') and states an operational limit of 5 checks per 30 minutes per IP, which shapes invocation. It does not say when to prefer this over the two sibling checks, so there are no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Bytespider, CCBot) can read a website, and whether it has llms.txt, schema markup and server-rendered content. Returns a 0-100 score and the failed checks.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website URL to check, starting with http:// or https://, e.g. https://example.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and open-world behavior, so the description focuses on adding value: it fetches a live site and returns a 0-100 score plus the failed checks. That gives the agent output shape and result semantics, which is meaningful since no output schema exists. It omits failure modes such as unreachable URLs or timeouts.
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 tight sentences, front-loading the operation and then the checks and return value. Nothing is redundant with the title and no filler is present.
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 one-parameter read-only audit with no output schema, the description covers what is checked and what comes back (score plus failed checks). It stops short of describing error behavior or the score's scale semantics beyond the 0-100 range.
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 single url parameter already documents format and an example. The description adds nothing about the URL beyond what the schema provides, so the 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?
States a specific verb (check) and resource (AI crawler readiness of a website), and enumerates the concrete checks it performs (bot access for named crawlers, llms.txt, schema markup, server-rendered content). An agent can distinguish this from validate_llms_txt (a single sub-check) and check_ai_citations without opening any 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?
The context of use is clear: a site-level readiness audit for AI crawlers. It does not explicitly name the siblings or say when to prefer validate_llms_txt over this broader check, so routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an llms.txt file. Pass a website URL to fetch and check its /llms.txt (or /llms-full.txt), or pass the llms.txt text itself. Returns a 0-100 score, valid true/false, and each check. Use it to check a site or to review text drafted for the user. If both are given, the url is used.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Website URL. The tool fetches its /llms.txt or /llms-full.txt. Leave empty when passing content. | |
| content | No | The llms.txt text to validate, up to 200,000 characters. Leave empty when passing url. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond that: it performs network fetches of /llms.txt or /llms-full.txt, and it returns a 0-100 score, a boolean, and per-check results. It omits what happens when the site lacks an llms.txt or when fetching fails, which keeps it from a 5.
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 short sentences, front-loaded with purpose, then inputs, then outputs, then precedence. Dense and scannable. Slight overlap between 'Pass a website URL to fetch...' and the closing precedence sentence, but nothing is wasted at length.
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?
No output schema exists, and the description compensates by naming the return shape (score, valid flag, individual checks). Combined with the input-mode explanation and precedence rule, an agent has everything needed to invoke it correctly and interpret results.
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 both parameters are already documented, giving a baseline of 3. The description does add one semantic not in the schema: the tie-break that url wins if both are provided. That is useful but marginal over schema-supplied meaning.
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 ('Validate an llms.txt file') and immediately enumerates both input modes (URL fetch vs. raw text). The siblings (check_ai_citations, check_ai_crawler_readiness) are distinct checks, and this description makes clear this one is specifically about llms.txt conformance.
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 usage scenarios: checking a live site, or reviewing text drafted for the user. It also states a precedence rule when both inputs are supplied. It stops short of naming when not to use it (e.g., non-llms.txt validation should go to a sibling), so it lands just under top marks.
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.
check_ai_citationscheck_ai_crawler_readinessvalidate_llms_txtFree AI crawler, schema, llms.txt and answer-readiness checks for public web pages. No API key.
Audit websites for AI search readiness and generate or validate llms.txt. Free quick check.
Free AI-readiness audit of any URL: AI crawler rules, JS-free text, JSON-LD, llms.txt. Tool catalog.
Free check whether a website is technically open to AI assistants (AI crawlers, llms.txt, JSON-LD).
Add one secure layer between your agents and this server.
