seo-geo-mcp-server

llms.txt Check

llms_txt_check

Read-onlyIdempotent

Checks if a site publishes /llms.txt and validates it against the llmstxt.org proposal, including required H1, optional summary, and H2 link sections. Also detects /llms-full.txt.

Instructions

Check whether a site publishes /llms.txt and validate it against the llmstxt.org proposal: a required H1 title, an optional blockquote summary, and H2-delimited lists of - [name](url): notes links. Also detects /llms-full.txt.

Important context this tool always reports: llms.txt is a community proposal from September 2024, not an adopted standard. No major AI vendor has documented that its crawlers read llms.txt from third-party sites, and Google has publicly stated it does not support it. Publishing one is cheap and may help human readers and some documentation tooling, but it does not earn AI visibility on its own — robots.txt access, structured data and server-rendered content do. Note also that llms-full.txt is a de-facto convention popularised by docs tooling, not part of the proposal.

Use this tool to answer "do they publish one, and is it well-formed?" — not as evidence that a site is or is not AI-optimised.

Args:

site (string): domain or any URL on it.
response_format ('markdown' | 'json'): output format (default 'markdown').

Returns: { found, status, full_variant_found, bytes, title, has_summary_blockquote, sections[], link_count, spec_compliant, adoption_status, findings[] }.

Example: "Does example.com publish an llms.txt?" -> llms_txt_check(site="example.com").

Input Schema

TableJSON Schema

Name	Required	Description	Default
`site`	Yes	Site domain or any URL on it, e.g. 'example.com'. Only the origin is used.
`response_format`	No	Output format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes
`bytes`	Yes
`found`	Yes
`title`	Yes
`status`	Yes
`findings`	Yes
`sections`	Yes
`link_count`	Yes
`spec_compliant`	Yes
`adoption_status`	Yes
`full_variant_found`	Yes
`has_optional_section`	Yes
`has_summary_blockquote`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.2.0Sep 16, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv1.0.0Aug 3, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only, idempotent, and open-world, so the safety profile is covered. The description adds valuable behavioral detail beyond that: it always reports adoption_status and explains the llms-full.txt convention, and it clarifies the tool's limitations regarding AI visibility. This gives the agent an accurate model of what the tool will and won't tell them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than the minimum but well-structured: the core action is front-loaded, followed by important contextual caveats, then args and returns. The extra context about llms.txt's non-adopted status is relevant to correct usage, so it earns its place. However, it could be tightened by omitting the schema-redundant parameter block.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema (per context signals), so the return-value list in the description is supplementary. The description covers the non-obvious aspects: validation criteria, full-variant detection, and the adoption-status context an agent needs to interpret results. With a simple two-parameter input and a live read-only check, nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter meaning is fully carried by the input schema. The description's Args section repeats the schema content without adding new semantics, and the example usage illustrates a call pattern rather than parameter meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Check whether a site publishes /llms.txt and validate it against the llmstxt.org proposal.' It also names the alternate variant detection (/llms-full.txt), which distinguishes it from sibling robots.txt/sitemap checks. An agent can immediately tell exactly what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use it: 'Use this tool to answer "do they publish one, and is it well-formed?"' and, more importantly, what not to use it for: 'not as evidence that a site is or is not AI-optimised.' It also embeds relevant context about llms.txt's non-standard status, which helps the agent decide if the tool is appropriate for a given user question.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server