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

Annotations only establish read-only/idempotent; the description goes well beyond by disclosing partial-failure semantics that matter operationally: nonexistent paths land in `missing` instead of erroring, overflow past 20 goes to `remaining`, and oversized pages are chunked out to `omitted` with sizes. That tells the agent the call degrades gracefully and that a short response may still mean more work remains.

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?

Front-loads the verb, resource, and batch size before any conditional detail, and every clause carries behavioral information rather than restating the name. It is packed into essentially one long sentence, which is dense but not padded.

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 carries the return-value burden and does name the three auxiliary fields (`missing`, `remaining`, `omitted`). It never describes the shape of the successful page payload itself (how content maps back to each path), leaving one modest gap for a tool whose primary return is page content.

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 both parameters are already documented, which sets the baseline at 3. The description adds one genuinely useful constraint, 'Pass `paths` as the listings return them,' warning against normalizing paths, plus the default and truncation behavior of `maxChars`, but it does not elaborate further.

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?

States a specific verb and resource with explicit scope: 'Batch read: 1 to 20 pages of the AcuiQ reference wiki in full in one call.' The batch framing plus the 1-20 cap immediately separates it from get_page (single) and list_pages/search_wiki (listing only).

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?

Gives a concrete triggering condition: 'which is how to read search or listing results,' tying it to the search/list siblings in the toolset. It omits an explicit inverse rule (use get_page for a single known page), so the routing guidance is clear but not fully closed.

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