ms_fetch_all

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

Annotations already mark the tool as readOnly and openWorld, and the description adds substantial behavior: it manages cursor fields, auto-derives the array path, enforces a max_items cap, and returns a truncated flag. This exceeds the structured data without contradicting it.

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 summary line is front-loaded, the Args section is a compact list, and the return shape is given in one line. There is no filler or repetition; 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?

For a 7-parameter tool with 0% schema descriptions and no destructive behavior, the description covers the operation, all parameters, pagination behavior, and the exact return envelope. An output schema exists, so the absence of deeper return-field documentation is 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?

Schema coverage is 0%, so the description must carry parameter meaning, and it does: operation_id is identified as 'a read endpoint from the catalog', query/body/path_values are called base parameters, items_path is an override, limit sets page size, and max_items caps the result. Every parameter receives semantic context beyond name and type.

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 first line names the operation and resource precisely: 'Auto-paginate a read endpoint and return every row in one response.' It is clear about the tool's function, but it does not explicitly name a sibling alternative such as ms_call_method or ms_get_raw, so it misses the differentiator needed for a 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?

The description clearly establishes the intended use case—fetching all rows from a read endpoint without manual pagination—and lists the pagination styles it supports. It does not explicitly state when not to use it or which sibling tool to choose instead, but the context is strong enough for an agent to route correctly in most cases.

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