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

No annotations exist, so the description carries the full burden. It adds two real behavioral notes: stored context is untrusted data (a security caveat), and this is a low-level tool that handles the read credential. It does not disclose read-only semantics explicitly, error behavior, or return shape. Decent but incomplete for a zero-annotation tool.

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?

Three tight sentences, front-loaded with the core purpose before the security note and the routing hint. Every sentence contributes; only minor loss for the compressed phrasing that leaves some gaps.

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?

Covers purpose, the untrusted-data caveat, and credential handling, which is reasonable for a 3-param read tool with no output schema. Missing: what read_token/address_id actually are, failure modes, and any return-format hint. Adequate but leaves an agent inferring a fair amount.

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%, so the description must compensate. It implies the key parameter's optionality by saying 'or list its keys' (omit key to list), and hints read_token is a credential via 'handles the read credential.' But address_id and the read_token format/scope remain undocumented in both schema and description.

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+resource: 'Read durable JSON context or list its keys.' This clearly distinguishes it from siblings set_state and delete_state, and the 'or list its keys' clause reveals dual behavior. It doesn't explicitly name siblings, but the read/write/delete triad is self-evident from the naming.

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?

Provides genuine routing guidance: 'prefer the credential-owning CLI helper,' which tells the agent this is a fallback for low-level use. It also flags that this tool 'handles the read credential.' However, it gives no guidance on when to use get_state versus set_state/delete_state, or how it relates to the event-polling siblings.

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