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

With no annotations, the description carries the full burden well: it declares read-only behavior, says it never returns tokens or keys, explains redaction of `reason`, clarifies the `bound` overlay is not GitHub binding, and notes queue degradation uses the same cheap probe as `health`.

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 purpose is front-loaded and the description is dense with relevant operational detail. It is longer than strictly necessary because it enumerates return fields despite an output schema existing, but the information is structured and mostly earns its place.

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?

Given an existing output schema and one optional parameter, the description is more than complete: it covers safety, return semantics, failure reasons, session binding nuances, and how it relates to `health`.

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 sole `repo` parameter has 100% schema description coverage, including its optionality and bound-agent behavior. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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 states a specific diagnostic purpose: seat-scoped memory status covering bind, session, capture, and queues. It distinguishes itself from the sibling `health` tool as service-level versus seat-scoped and explicitly says it does not mutate memory.

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?

It provides clear context by saying it complements service-level `health` and is read-only/non-mutating. However, it does not give an explicit 'use this when...' rule or name when to prefer `health` over `memory_status` in concrete terms.

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