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

Adds context the annotations cannot express: the effect is externally visible to the sender, it is a human-attributed signal rather than a fetch, and repeats are a no-op ('a second call adds nothing') — sharpening idempotentHint=true into practical guidance. It stops short of noting whether the sender can see who/when or any throttling, so not a 5.

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 the action, then triggers, then the idempotency and ownership constraints. The appositive clause about 'a page or a tool fetched it' is slightly ornate but earns its place by contrasting with read tools.

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, non-destructive action with annotations and no output schema, everything needed is present: what happens, when to call, that repeats are harmless, and the self-send restriction. No material gaps for correct 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?

Single parameter with 100% schema coverage; the schema already explains that packageId comes from check_inbox, whats_new, get_thread, or thread_status. The description adds no further format or sourcing detail, so the baseline 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?

States a specific verb and resource ('Tell the sender the user has read one of their packages') and goes further to define the semantic meaning of the action versus passive fetches. Clearly distinguishable from siblings like get_package or check_inbox, which read but do not signal.

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?

Explicit triggers are given ('Offer it after reading a package aloud, and call it when the user says to'), plus an explicit exclusion ('The user cannot acknowledge a package they sent'). This is the when/when-not/trigger pattern at full strength.

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