Reads your latest 20 bell notifications and how many are still unread (reading them here does NOT mark them as read).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| unread | Yes | How many unread notifications the account has. | |
| notifications | Yes | The 20 most recent ones, already written in the token's language. |
Changes observed during successful MCP inspections.
Output schema / properties / notifications / descriptionPrevious value: -"Las 20 más recientes, ya redactadas en el idioma del token."New value: +"The 20 most recent ones, already written in the token's language."Output schema / properties / notifications / items / properties / date / descriptionPrevious value: -"Cuándo se creó (ISO)."New value: +"When it was created (ISO)."Output schema / properties / notifications / items / properties / link / descriptionPrevious value: -"Ruta interna a la que lleva, si tiene."New value: +"Internal path it leads to, if it has one."Output schema / properties / notifications / items / properties / read / descriptionPrevious value: -"Ya estaba leída."New value: +"It was already read."Output schema / properties / notifications / items / properties / text / descriptionPrevious value: -"Cuerpo de la notificación."New value: +"Body of the notification."Output schema / properties / notifications / items / properties / title / descriptionPrevious value: -"Titular de la notificación."New value: +"Headline of the notification."Output schema / properties / unread / descriptionPrevious value: -"Cuántas notificaciones sin leer tiene la cuenta."New value: +"How many unread notifications the account has."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses a non-obvious behavioral trait: 'reading them here does NOT mark them as read.' This is high-value transparency for a notification-reading tool, and no annotations were present to supply it.
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 description is a single, front-loaded sentence that covers action, scope, and the critical side-effect caveat without any filler or repetition.
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 no-parameter read-only tool with an output schema, the description states exactly what the agent will receive (latest 20 notifications and unread count) and the important non-marking behavior. There are no ambiguous inputs or missing prerequisites an agent would need to know.
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 takes zero parameters and the input schema is empty, so there is no parameter semantics to document. Baseline 4 is appropriate as the description fully covers the tool's fixed behavior.
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?
Description names the specific action ('Reads'), the exact resource ('your latest 20 bell notifications'), and the key outcome ('how many are still unread'). It also adds the crucial distinction that reading here does not mark notifications as read, which prevents it from being confused with a potential mark-as-read tool.
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?
The description clearly implies the use case: check the latest 20 bell notifications and see the unread count. It does not name sibling alternatives, but no sibling appears to compete for this behavior, so the lack of explicit exclusions is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.