notifications_filtersList every option used to define alert conditions—category, matter type, level, expected volume, and retention window—so each rule targets the right events.
Каталог видов, дел, уровней, числа записей и срок хранения.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, which fully covers the safety profile. The description adds nothing behavioral beyond that — no indication of the shape of the returned catalog, whether values are scoped per account, or how it relates to live notification queries.
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?
One short, front-loaded clause with no filler. It is economical, though it is terse to the point of under-specification rather than tight exposition.
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-param discovery tool the description is the main information channel, since there is no output schema to describe the returned catalog. It leaves the agent without the return shape, the intended call order relative to notifications_list/summary/settings, or any context on scope.
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 is 4. The description's enumeration of catalog dimensions (types, cases, levels, counts, retention) is metadata about the tool's output rather than about inputs, but no parameter semantics are missing.
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 bare noun list ('catalog of types, cases, levels, record counts and retention periods') with no verb, so it never states that the tool returns available filter values. A reader can guess the resource is filter metadata, but it is not differentiated from close siblings such as audit_filters, notifications_list, or notifications_summary.
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 prerequisite, and no named alternative. An agent cannot tell from this text whether to call notifications_filters before notifications_list, or instead of notifications_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.