read_wiki

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns for each topic form, and it explicitly describes pagination behavior: long pages arrive in parts, `truncated` indicates more content, and `hint` tells how to request it. This is meaningful behavioral detail beyond the schema.

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 compact and well-structured. The first sentence states the tool's core value and appropriate use. The second paragraph covers topic semantics and pagination without unnecessary detail. Every sentence earns its place.

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?

Given only two parameters, no annotations, and no output schema, the description covers the essential behavior: what the tool reads, how topic maps to content, and how pagination works. It could be slightly more explicit about the `part` parameter, but the overall picture is complete enough for an agent to call the tool 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 description coverage is 0%, so the description must compensate. It thoroughly explains `topic` semantics: a setting key yields a settings section, and a search_wiki page name yields a page. The `part` parameter is covered indirectly through the pagination explanation and the `hint` reference, which is enough to infer how to request additional parts.

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 names a specific action and resource: reading the authoritative wiki on one topic. It clearly distinguishes the tool from search_wiki by explaining that topic can be a setting key or a page name from search_wiki, and it positions the tool as the source of truth for procedures and recommended values.

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 gives clear usage context: use this instead of relying on memory for procedures and recommended values. It also explains the two input types—setting keys and search_wiki page names—and implies search_wiki is the discovery step. It stops short of explicitly naming exclusions or alternative sibling tools, but the guidance is strong.

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