List item groups

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful provenance — these parameters were inferred from the web app's own traffic and results should be confirmed — plus the response keys (draw, recordsTotal, recordsFiltered, data, meta, table_id, settings) despite no output 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 lead sentence and route are well front-loaded, but roughly 60 parameter names are dumped into the description, duplicating the schema key-for-key with no explanatory value. This bulk obscures the two sentences that actually matter (the traffic-inference caveat and the response keys).

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 59-parameter DataTables-style endpoint with no output schema, the description does supply the return keys and a reliability caveat, which is more than nothing. However, it never explains what an item group is, which parameters are meaningful for filtering, or what the `data` entries contain, leaving real gaps for a complex tool.

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 nominally 100%, but every entry is a tautology (e.g. 'Query parameter "draw"'), so neither schema nor description explains what any parameter does. The description's phrase 'Query params seen' does convey that these are observed and effectively optional, but otherwise it repeats the schema key list verbatim rather than adding meaning.

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 clear verb and resource ('List item groups') and pins it to the underlying route (GET /item_groups), so an agent knows exactly what it retrieves. It does not differentiate from close siblings such as singleops_read_list_items or singleops_read_get_item_groups_report, which keeps it out of 5 territory.

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?

There is no statement of when to use this versus the sibling item-group report or items list, and no prerequisites or exclusions. The only usage-adjacent content is the caveat 'confirm results', which warns about reliability rather than routing the agent.

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