Check total unread messages, oldest message age, and per-project counts across global and registered project inboxes before reading a user inbox to see if anything is waiting.
Cheap peek across the global inbox + every registered project inbox. Returns total unread count, age of the oldest message, and a per-project breakdown. Call before read_user_inbox if you only want to know whether anything is waiting.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v2.2.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description makes the read-only, lightweight nature clear through "cheap peek" and the stated return values. It discloses scope across the global inbox and every registered project inbox, though it does not explicitly state that no side effects occur.
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-loads the core purpose, then states the return values, then gives the usage rule. Three short sentences with no filler.
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 zero-parameter, no-output-schema tool, the description supplies the key return information: total unread count, age of oldest message, and per-project breakdown. That is enough for an agent to decide whether to call it and what to expect.
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 tool has zero parameters, so there are no parameter semantics to document. The schema is empty and the description correctly focuses on behavior and return values rather than invented arguments.
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 resource and action: a cheap peek across the global inbox and all registered project inboxes. It also explicitly distinguishes this from read_user_inbox by saying to call it when you only need to know whether anything is waiting.
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 explicit routing guidance: call this before read_user_inbox if you only want to know whether anything is waiting. That clearly frames the alternative and the condition under which this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.