Skip to main content
Glama
Akxan
by Akxan

Draft an llms.txt from the sitemap

llms_txt_generate
Read-onlyIdempotent

Crawl your sitemap, read page titles and meta descriptions, and generate a review-ready llms.txt draft with standard formatting for your site.

Instructions

Crawl the sitemap (up to maxPages), read each page's title and meta description, and produce a draft llms.txt in the standard format (H1, blockquote summary, H2 sections grouped by first path segment, '- title: description' lines). Review and edit the draft before publishing it at /llms.txt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteUrlYes
summaryNoBlockquote summary; defaults to the homepage meta description.
maxPagesNo
siteNameNoOverride the H1; defaults to the homepage <title>.
excludePatternsNoSkip URLs containing any of these substrings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.3.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context: it crawls up to maxPages, reads each page's title and meta description, groups output by first path segment, and does not publish the file itself.

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

Conciseness5/5

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

Two dense sentences with no filler. The action is front-loaded, the output format is specified compactly, and the workflow instruction earns its place.

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?

There is no output schema, but the description details the generated output format and the expected follow-up workflow. For a generation tool with annotations covering safety, this is complete enough for an agent to understand what to expect.

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 60%, and the description references maxPages and siteUrl implicitly through sitemap crawling. However, it does not clarify summary, siteName, or excludePatterns beyond what the schema already says, so it only partially compensates for the gap.

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 uses specific verbs and resources: crawl the sitemap, read page titles and meta descriptions, and produce a draft llms.txt. It also clarifies the standard output format, making it easy to distinguish from sibling tools like llms_txt_check.

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 a clear workflow context: generate a draft, review and edit it, then publish it at /llms.txt. It does not explicitly name alternatives or when-not-to-use conditions, but the use case is clearly implied.

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