List agent interactions

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's ordering guarantee (created_at asc, then id asc) is a genuine behavioral trait beyond the annotations and is relevant to stable cursor pagination. It says nothing about paging behavior, result volume, or auth requirements, so it is only partial.

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?

A single front-loaded sentence with zero filler, which is structurally clean. However, for a seven-parameter listing tool the brevity reads as under-specification rather than disciplined conciseness.

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?

Seven parameters (three required), 43% schema coverage, no output schema, and only one sentence of prose. An agent calling this cannot tell what an 'interaction' is, how paging terminates, or how state/include_subagents affect results, so the description is inadequate for the tool's complexity.

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 43%; orgID, state, agentID and projectID carry no descriptions, and the description adds no meaning for any of the seven parameters. Its mention of created_at/id hints at pagination stability but never ties to cursor or limit. It does not compensate for the coverage gap, so it falls below the baseline 3.

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 never states what the tool does; it only says how returned items are ordered. The purpose is recoverable only from the name/title ('List agent interactions'), so the description itself is effectively a restatement plus a sorting detail. It also gives no differentiation from siblings such as agents_events_list or agents_interactions_resolve.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many agents_* siblings. An agent gets no signal about when to call this versus agents_events_list or agents_get.

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