Reset the unread notification count in Backlog to clear notification badges and mark existing notifications as read.
Reset unread notification count
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.15.1v0.13.1v0.11.0Input schema / additionalPropertiesAdded value: +falseInput schema / properties / organizationAdded value: +{
+ "description": "Optional organization name. Use list_organizations to inspect available organizations.",
+ "type": "string"
+}v1.0.0Input schema / additionalPropertiesRemoved value: -falseDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose that this mutates state (readOnlyHint=false), is idempotent, and is non-destructive, so the description is not required to carry the full safety burden. It nonetheless adds nothing: it does not clarify what 'reset' means (to zero, or clearing the unread flag), whether the operation is scoped to the caller, or whether reset is recoverable.
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?
It is a single short, front-loaded sentence with no filler, so it is not bloated. The problem is under-specification rather than verbosity — the one sentence carries no information beyond the tool name.
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?
The surface is simple (no params, no output schema, no nested objects), and annotations cover the mutation/idempotency profile, so a minimal description is defensible. Still, for a state-changing reset operation the agent would benefit from knowing the scope of the reset and what the response indicates.
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, so the baseline for this dimension is 4. Nothing in the description conflicts with the empty schema, although nothing is added either.
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?
The description is a verbatim restatement of the tool name with spaces instead of underscores, adding no scope, target, or effect detail. An agent learns nothing beyond what the identifier already said, and it is not distinguished from siblings such as mark_notification_as_read or count_notifications.
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?
There is no when-to-use guidance, no exclusion of alternatives, and no statement of prerequisites. An agent cannot infer from the text whether this clears notifications for the current user only, all users, or only already-read ones, nor how it relates to mark_notification_as_read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.