Check local live-session status

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond annotations by explicitly listing what is NOT returned (pairing codes, invitations, received contents, device labels, media) and clarifying the scope is this adapter process. It does not describe error behavior or whether one or all sessions are returned.

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 description is three compact sentences with no filler. It front-loads the return-content summary and uses the remaining sentences for exclusions and process scope. It could be slightly more front-loaded around the action rather than the return payload.

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, the description appropriately explains returned fields and exclusions, which is essential. Annotations cover the safety profile well. However, the lone parameter's behavior is left entirely undocumented, leaving a clear completeness gap for an agent deciding whether/how to pass session_id.

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?

There is one optional parameter (session_id) with UUID format, but schema description coverage is 0%. The description never mentions session_id or explains whether it filters to a single session or is ignored. With low schema coverage, the description should compensate, and it does not.

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 specifies the exact return payload of a status check (session types, safe state, peer counts, capture kind, expiry, saved-file counts). Combined with the title, an agent can identify this as a read-only status tool. It is clear but does not explicitly name a sibling alternative or give a direct action verb like 'check'.

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 offers no when-to-use guidance, no prerequisites, and no explicit alternatives among siblings like abox_live_stop or the various session tools. The statement 'Sessions belong to this adapter process' is scoping context, not usage guidance. Purpose is implied only by the tool name and title.

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