Fetch llms.txt page

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses that long pages arrive in chunks with the next offset noted in the response, and it flags that returned text is implementation guidance rather than behavioral instruction — a genuinely useful prompt-injection guard. These are behaviors the annotations cannot express.

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

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

The chunking/return behavior is front-loaded in the first two sentences, followed by the content-safety note and the URL/llms-full.txt guidance. Dense but every sentence carries distinct information; no filler.

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

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

With no output schema, the description compensates by describing the return shape (markdown text, chunked, offset for continuation), the URL provenance requirement, and the content-policy caveat. An agent has everything needed to call it and interpret the result correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: the `url` must be taken as-is from llms_index or llms_search (no guessing), and `offset` is framed as the continuation point for chunked reads, which explains its purpose beyond the schema's 'character position' wording.

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

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

The description states a specific resource (a full documentation page) and its retrieval mode (chunked by the configured cap), which distinguishes it from llms_search and llms_index in practice. The verb is only implied by the tool name rather than stated outright, so it lands at 4 rather than 5.

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

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

It gives explicit routing: llms-full.txt is not read through this tool and must go via llms_search with scope=full, and it tells the agent to take the address from the index verbatim rather than guessing language segments, versions, or a trailing `.md`. It does not spell out when to prefer this over llms_index for a normal page, but the exclusions are concrete and actionable.

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