get_session

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Retrieve' clearly signals a non-mutating read operation, and the description enumerates what will be returned. It does not discuss failure conditions or payload size, but that is acceptable for a straightforward getter.

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 a single sentence with no filler. The action, target, and return categories are all front-loaded, and every word contributes to the agent's understanding.

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 one-parameter read tool with no output schema, the description gives a complete high-level contract: it states the input (via schema) and the return categories (metadata, capabilities, health, statistics). It could be more complete by explicitly noting non-destructive behavior or naming relevant siblings, but nothing essential is missing for selection and invocation.

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 only parameter, sessionId, is already fully documented in the schema with 100% coverage, and the description adds no additional parameter-level meaning. Per the baseline for high schema coverage, this is correctly rated at 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 opens with a specific verb ('Retrieve') and clearly identifies the resource ('a specific debugging session') and the data categories returned (metadata, capabilities, health status, statistics). This distinguishes it from siblings like list_sessions (collection) and delete_session (mutation) without needing to open their schemas.

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 phrase 'specific debugging session' implies this is the point-lookup counterpart to list_sessions, but the description never explicitly says when to use it versus alternatives such as get_recording_health or get_diagnostics. Usage guidance is present only by implication, not direct instruction.

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