Read messages from Claude Code

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

The description discloses the key side effect — messages are marked read, which is a state mutation consistent with readOnlyHint=false and non-idempotent behavior. It also discloses ordering (oldest first) and that unscoped reads include messages outside any session, context the annotations cannot convey. It doesn't mention that marking read is irreversible or how the limit interacts with the read-marking.

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?

Two sentences, no filler, with the core action and its side effect front-loaded and the parameter behavior following. Every clause adds information an agent needs.

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 three-parameter, no-output-schema read tool, the description covers purpose, ordering, scope, and the mark-read side effect adequately. It stops short of describing what a returned message looks like or how limit affects which messages get marked read, but nothing essential to invoking it correctly is missing.

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 coverage is only 33% (only wait_seconds is documented), so the description must compensate, and it does so for the most ambiguous parameter: session_id, explaining that omission means everything including session-less messages. The limit parameter is left entirely unexplained in both description and schema, which is the remaining gap.

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?

"Read unread messages that Claude Code sent you" states a specific verb and resource, and adds scope detail (unread only, oldest first). It doesn't name a sibling like read_reports or send_message to differentiate itself, so an agent must infer the split from names alone.

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 explains the two calling modes (pass a session_id for one session, omit it for everything) which implies when each is appropriate. But there is no explicit when-to-use-vs-alternatives guidance against siblings such as read_reports, nor any statement of when not to call it.

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