List terminal sessions

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description's only extra signal is the word 'retained', which hints at persisted/historical sessions, but it does not say whether live sessions are included, how results are ordered or paginated, or what a session record contains.

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?

One short sentence with no padding, so it is concise, but it is terse to the point of under-specification. Nothing is front-loaded beyond the bare action.

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?

With no output schema, zero parameter documentation, and an ambiguous core noun ('session'), the description leaves too much for the agent to infer. Given the dense sibling list of process and session tools, it needs to define scope and filtering behavior and does not.

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 0% for both deviceId and deviceName, so the schema supplies no meaning at all, and the description does not compensate by explaining whether these are filters, what format a deviceId takes, or whether omitting them returns all devices' sessions.

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 has a clear verb+resource ('List ... sessions'), but the noun 'Raccoon process sessions' is undefined and it never distinguishes itself from the many near-identical siblings such as list_processes, process_list, and db_query_sessions. An agent cannot tell from this text what a 'session' is versus a 'process'.

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 any alternative tool. The sibling set contains at least three plausible substitutes (list_processes, process_list, db_query_sessions), and nothing here routes the agent to or away from them.

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