Skip to main content
Glama

Generate AI visibility files

generate_ai_visibility_files
Read-only

Generate ready-to-publish llms.txt, an AI-bot-friendly robots.txt and schema.org JSON-LD for a website, based on its current homepage.

Input Schema

NameRequiredDescriptionDefault
urlYesWebsite URL, e.g. https://example.com

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous value: -"Website URL"New value: +"Website URL, e.g. https://example.com"
  2. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with both (it fetches the live homepage, generates content, mutates nothing). It adds that generation is grounded in the current homepage, but says nothing about where the files go, whether anything is written to a server, rate limits, or output delivery, so it stays near the baseline.

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?

One sentence, verb and artifacts front-loaded, no filler or restated title. Every clause carries information an agent needs.

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

Completeness3/5

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

With one required parameter and no output schema, the description tells the agent what is produced but not how it is returned (inline text, files, links) or what happens if the homepage lacks the relevant content. Adequate for invocation, thin for a generation tool whose whole value is the returned artifacts.

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

Parameters4/5

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

Schema coverage is already 100% for the single url parameter, so the baseline is 3. The description adds a real nuance the schema lacks: the URL should be the site's homepage and it is that page's current content which drives generation, which affects what the agent should pass.

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

Purpose4/5

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

States a specific verb (generate) and three named artifacts (llms.txt, an AI-bot-friendly robots.txt, schema.org JSON-LD) plus the input source (the site's current homepage). The verb alone separates it from validate_llms_txt and audit_ai_visibility, but it never names those siblings or explicitly disclaims the overlap, so differentiation is inferred rather than stated.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as validate_llms_txt (check an existing file) or audit_ai_visibility (assess current state). The phrase 'ready-to-publish' hints at a post-audit workflow, but nothing tells the agent when this tool is the right call.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources