Wiki lookup

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

With no annotations, the description carries the full burden and delivers extensively. It discloses multi-hop redirect following, section fragment resolution, disk cache with 30-day TTL, refresh bypass, pure HTTP operation without the game, and the exact return payload shape including error case for not-found pages. This is exemplary behavioral disclosure.

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 description is concise and front-loaded with the primary action, then layers in behavioral nuances in a logical order: redirects/fragments, caching, operational dependency, and return format. Every sentence carries distinct information with no redundancy or filler, achieving high information density in a compact form.

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?

Despite no output schema, the description fully specifies the return object and error behavior. It covers all major context needed to invoke the tool: article title, section scoping, cache behavior, and runtime independence. The tool's complexity is well-addressed, and it stands clearly apart from the sibling wiki_search tool.

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?

The schema already provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds meaningful context beyond the schema by explaining how refresh bypasses the cache and by giving a concrete example of section fragment resolution ('Weapon trap' to the Trap page section), which helps the agent understand the section parameter's behavior more intuitively.

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 opens with a specific verb+resource: 'Fetch a Dwarf Fortress wiki article as clean, readable text,' clearly distinguishing this from the sibling tool wiki_search by focusing on retrieval of a specific article rather than search. It also specifies the DF2014 namespace scope, making the purpose unambiguous.

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?

The description provides clear context on when to use the tool: to get a clean-text version of a wiki article, with redirect and section handling, and works without the game running. It does not explicitly name alternatives or say 'use wiki_search instead for fuzzy lookups,' but the fetch-vs-search distinction is implicit and sufficient for an agent to choose correctly.

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