Skip to main content
Glama
OrtaMarco

seo-geo-mcp-server

by OrtaMarco

llms.txt Check

llms_txt_check
Read-onlyIdempotent

Check whether a site publishes llms.txt and validate it against the llmstxt.org spec: required title, summary, and link sections. Also detects llms-full.txt and reports adoption status.

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
NameRequiredDescriptionDefault
siteYesSite domain or any URL on it, e.g. 'example.com'. Only the origin is used.
response_formatNoOutput format: 'markdown' for a human-readable summary (default) or 'json' for the full structured payload.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
bytesYes
foundYes
titleYes
statusYes
findingsYes
sectionsYes
link_countYes
spec_compliantYes
adoption_statusYes
full_variant_foundYes
has_optional_sectionYes
has_summary_blockquoteYes
Behavior5/5

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

Annotations already indicate readOnly, idempotent, openWorld, and non-destructive behavior. The description adds significant behavioral context, including that the tool 'always reports' adoption status and important caveats about llms.txt not being a standard, plus detection of llms-full.txt. This goes well beyond 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.

Conciseness4/5

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

The description is well-organized and front-loaded with a clear purpose statement. The 'Important context' paragraph, Args, Returns, and Example sections are clearly structured. It is longer than a minimal description, but every section adds value and the formatting aids scannability.

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

Completeness4/5

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

The description covers the tool's purpose, validation criteria, important caveats, parameters, return fields, and an example invocation. This is thorough especially with annotations present. It lacks only minor details like error-handling behavior, but overall it is complete enough for an AI agent to use correctly.

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 both parameters are already fully documented. The description's Args section merely restates the schema information without adding new semantic details. Thus, the baseline of 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 clearly states the tool's function: 'Check whether a site publishes /llms.txt and validate it against the llmstxt.org proposal' and also mentions detection of /llms-full.txt. It includes specific details on what is validated (H1, blockquote, H2 lists) and directly answers the tool's purpose: 'Use this tool to answer "do they publish one, and is it well-formed?"' This distinguishes it from sibling tools.

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

Usage Guidelines4/5

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

The description provides explicit when-to-use guidance: 'Use this tool to answer "do they publish one, and is it well-formed?"' and an explicit when-not: 'not as evidence that a site is or is not AI-optimised.' It does not name alternative tools, but the context makes the intended usage clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OrtaMarco/seo-geo-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server