Search tasks (server-side table query: paging, sorting, filters)

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint false), so the bar is lower, but the description still adds real value: it explains the unusual read-as-POST pattern ('filters go in body'), warns that the shape was inferred from observed web traffic and must be confirmed, and lists the response keys. It stops short of describing pagination limits, rate behavior, or default result sizes.

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 useful content is front-loaded, but roughly two-thirds of the text is a mechanical, repetitive enumeration of columns[0] through columns[6] sub-keys that could have been summarized in one sentence. The list is also truncated mid-pattern ('columns[6][searchable]'), which wastes space without being complete.

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?

There is no output schema, and the description does supply the return keys (draw, recordsTotal, recordsFiltered, data, meta, table_id, settings), which is adequate. However, a tool whose headline promise is 'paging' lists no offset/limit keys and gives no guidance on how to actually page, and it offers no field semantics for the task columns an agent would filter on.

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 nominally 100%, but the schema's 'body' property is an empty object that explicitly defers to the description ('Match the fields listed in the description'), so the key dump is the only real parameter documentation available. It enumerates the DataTables-style keys but does not explain their meaning (that draw is an echo counter, that search[value] is the actual filter, that ordering is per-column), and it omits start/length paging keys entirely.

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 (search tasks) plus the mechanism (server-side table query with paging, sorting, filters) and the concrete endpoint POST /tasks/data_table/all. It is clear what the tool does, but it never distinguishes itself from the many sibling task readers such as singleops_read_list_tasks_calendar, singleops_read_list_tasks_route_planner, or singleops_read_list_client_tasks.

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?

Usage is only implied: 'server-side table query: paging, sorting, filters' suggests reaching for this when you need a filtered/paged task table rather than a fixed report. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling, and the 'confirm results' caveat gives no routing guidance.

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