wb_fetch_all

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

Annotations already provide readOnlyHint and openWorldHint; the description adds valuable context: cursor fields are auto-managed, max_items (default 10000) protects context, and extra keys are ignored. The truncated flag and page-capping behavior are disclosed beyond what annotations convey. No contradiction with annotations.

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 purpose is front-loaded in the first sentence, followed by a scannable list of supported pagination styles, then a compact Args block. Every sentence earns its place; nothing is redundant.

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 an output schema being present, the description still documents the return envelope ({ok, items, total_fetched, pages_fetched, truncated}) and fully covers all 7 parameters, which is critical given 0% schema coverage. A minor gap is the lack of a concrete example of items_path or per-endpoint pagination quirks, but the catalog hub makes this acceptable.

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?

With 0% schema coverage, the description carries the full burden and largely succeeds: it explains operation_id as a catalog read endpoint, query/body/path_values as base parameters with cursor fields managed, items_path as an array-path override, and defaults for limit and max_items. It could be slightly more explicit about how cursor management interacts with user-supplied query values.

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 verb and resource: 'Auto-paginate a read endpoint and return every row in one response.' The read-endpoint scoping distinguishes it from mutation siblings like wb_set_price and from single-call tools like wb_call_method, so an agent can tell them apart.

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 clearly conveys when to use it — when you want every row from a read endpoint rather than a single page — and enumerates the pagination styles it handles. It stops short of explicitly naming alternatives such as wb_call_method or stating when not to use it, so it lacks an explicit exclusion.

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