Skip to main content
Glama

fetch_llms_txt

Retrieve content from llms.txt URLs to access AI documentation or find references to additional llms.txt files, aiding developers in delivering context to AI IDEs.

Instructions

Fetches the content of one or more llms.txt URLs. Some llms.txt files compile a list of urls to other llms.txt file locations because listing their full documentation would bloat context. If the documentation you're looking for does not exist in the llms.txt, look for reference links to other llms.txt files and follow those.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputYesURL string, URL object, or array of URL/objects to fetch llms.txt from

Implementation Reference

  • The primary handler function for the 'fetch_llms_txt' tool. It normalizes input URLs, validates and parses targets, checks domain access, fetches content from each URL, and returns an array of TextContent results.
    export const fetch_llms_txt = async (
      input: UrlFetchInput,
      extra: RequestHandlerExtra<ServerRequest, ServerNotification>,
      allowedDomains: Set<string>
    ): Promise<CallToolResult> => {
      logger.debug("Processing fetch_llms_txt request with input:", input);
    
      // Normalize input to always be an array of { url: string } objects
      const urlList = normalizeUrlInput(input);
      const results: TextContent[] = [];
    
      for (const urlItem of urlList) {
        const url = urlItem.url;
    
        try {
          logger.debug(`Processing URL: ${url}`);
    
          // Validate the URL and get target info using the library function
          const targetInfo = await parseFetchTarget(url);
          if (targetInfo.type === "unsupported") {
            const errorMsg = `Unsupported URL format: ${targetInfo.reason}`;
            logger.error(errorMsg);
            throw new Error(errorMsg);
          }
    
          logger.debug(`Target info:`, targetInfo);
    
          // Check domain access using the library function
          checkDomainAccess(targetInfo, allowedDomains);
    
          logger.debug(`Fetching content from: ${url}`);
    
          // Fetch the content using the library function
          const fileContent = await fetchContent(targetInfo);
          results.push({
            type: "text",
            text: fileContent,
          });
    
          logger.debug(
            `Successfully fetched ${fileContent.length} bytes from ${url}`
          );
        } catch (error) {
          const errorMsg = `Failed to process fetch request for ${url}: ${
            error instanceof Error ? error.message : String(error)
          }`;
          logger.error(errorMsg);
          throw new Error(errorMsg);
        }
      }
    
      logger.debug(`Successfully processed ${results.length} URLs`);
      return {
        content: results,
      };
    };
  • Zod schema (UrlFetchInputSchema) and type (UrlFetchInput) defining the input validation for the fetch_llms_txt tool, supporting single URL strings, objects, or arrays thereof.
    import { z } from "zod";
    
    /**
     * Schema for URL-based fetch operations that can accept:
     * - A single URL string
     * - A single URL object
     * - An array of URL strings and/or objects
     */
    export const UrlFetchInputSchema = z.union([
      z.string().url("Input must be a valid URL string"),
      z.object({
        url: z
          .string()
          .url("Input must contain a valid URL string under the 'url' key"),
      }),
      z.array(
        z.union([
          z.string().url("Each array item must be a valid URL string"),
          z.object({
            url: z
              .string()
              .url(
                "Each array item must contain a valid URL string under the 'url' key"
              ),
          }),
        ])
      ),
    ]);
    
    // Type exports for use in function parameters
    export type UrlFetchInput = z.infer<typeof UrlFetchInputSchema>;
  • src/index.ts:122-140 (registration)
    Registration of the 'fetch_llms_txt' tool using server.tool(), including prompt, input schema reference, and wrapper handler that delegates to the main fetch_llms_txt function.
      "fetch_llms_txt",
      "Fetches the content of one or more llms.txt URLs. Some llms.txt files compile a list of urls to other llms.txt file locations because listing their full documentation would bloat context. If the documentation you're looking for does not exist in the llms.txt, look for reference links to other llms.txt files and follow those.",
      {
        input: UrlFetchInputSchema.describe(
          "URL string, URL object, or array of URL/objects to fetch llms.txt from"
        ),
      },
      async (params, extra) => {
        const input = params?.input ?? params;
        if (!input) {
          throw new Error("No input provided to fetch_llms_txt");
        }
        return fetch_llms_txt(
          input,
          extra as RequestHandlerExtra<ServerRequest, ServerNotification>,
          allowedDomains
        );
      }
    );
  • src/index.ts:78-89 (registration)
    Tool capability declaration in the MCP server constructor, specifying name, description, input schema, and annotations for 'fetch_llms_txt'.
    fetch_llms_txt: {
      name: "fetch_llms_txt",
      description: "Fetches the content of a llms.txt url.",
      inputSchema: UrlFetchInputSchema,
      annotations: {
        title: "Fetch llms.txt content",
        readOnlyHint: true,
        destructiveHint: false,
        idempotentHint: true,
        openWorldHint: true,
      },
    },
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions that llms.txt files can compile lists of URLs and suggests following references, which adds some behavioral context. However, it lacks details on error handling, rate limits, authentication needs, or what happens if URLs are invalid, leaving significant gaps for a tool that fetches external content.

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 appropriately sized with two sentences that convey key information: the core function and a usage tip about following links. It's front-loaded with the main purpose, though the second sentence could be more tightly integrated to avoid slight redundancy.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that fetches external URLs. It lacks details on return values (e.g., content format, error responses), authentication, rate limits, or how to handle multiple URLs, making it inadequate for safe and effective use by an AI agent.

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?

The schema description coverage is 100%, with the parameter 'input' well-documented as accepting URL strings, objects, or arrays. The description doesn't add any parameter-specific semantics beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without extra value.

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?

The description clearly states the action ('fetches the content') and resource ('one or more llms.txt URLs'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_llms_txt_sources' which might list URLs rather than fetch content, leaving some ambiguity.

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

Usage Guidelines3/5

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

The description implies usage by explaining that llms.txt files may contain links to other files, suggesting this tool is for following such references. However, it doesn't explicitly state when to use this tool versus alternatives like 'fetch_openapi_spec' or 'list_llms_txt_sources', providing only contextual hints rather than clear guidelines.

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

Related 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/maverickg59/sushimcp'

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