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

Goes well beyond the annotations by enumerating returned fields, explaining that activity is the last signal received and explicitly warning that activity does not mean availability. It also discloses a side effect the annotations do not imply: passing my_session_id registers that session as active, a state change not reflected in readOnlyHint=true. The disclosure is honest and useful, though the description never reconciles that write-ish side effect with the read-only framing.

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?

Front-loaded with purpose and the send_message link, then a compact field inventory and a clarifying caveat about activity. Slightly list-heavy, and the Args block is somewhat redundant with the earlier mention of my_session_id, but with no output schema the field enumeration earns its space.

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 compensates by documenting each returned field's meaning and usability (label as `to`, can_message with why_not, active_sessions window). For a one-optional-parameter read tool, an agent has everything needed to call it and interpret results.

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?

The single parameter has 0% schema description coverage (only type string, default ''), so the description carries the full burden and does: it says the parameter is optional, what value to supply (current session ID), and the downstream consequence of supplying it (session registered as active so other sessions can address it). That is meaning beyond anything the schema conveys.

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 ('List the agents in the user's workspace') and adds the discriminating scope 'that can be messaged', then names the consumer tool: finding the recipient for send_message. An agent can tell at a glance this is the recipient-discovery step, not a directory dump.

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?

Clear usage context: call this before send_message to find a valid `to` value. It also explains the conditional behavior of passing my_session_id. It does not explicitly say when not to use it (e.g., versus whoami for the caller's own identity), so it stops short of full when/when-not guidance.

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