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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely useful non-annotation behavior: results arrive in parts and you must re-call with the offset the answer names, and the operation is free of charge (no credit consumption). It does not describe ordering guarantees beyond 'newest first' for the list mode.

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?

Two dense sentences, front-loaded with the mode distinction and followed by pagination and cost notes; no filler. Density is high but every clause carries information an agent needs, with only a mild readability cost from packing both modes into one sentence.

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 read-only, paginated, dual-mode tool with a 6-parameter schema and an output schema, the description covers mode selection, pagination mechanics and cost. Return-value detail is correctly left to the output schema; only minor gaps remain, such as what a 'check' contains at the list level.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: check_id acts as a mode switch that changes the entire response shape, page_status is what selects the other page categories, and the offset is meant to be taken from the previous answer rather than guessed. That is more than restating the schema.

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+resource and cleanly splits the tool into two modes keyed on check_id: without it, the monitor's recent checks with counts and credits; with it, changed/new/removed/error pages plus KI-Bewertung reasons and diff excerpts. An agent can distinguish this from ragfeed_monitor_get, ragfeed_monitor_run and ragfeed_monitor_list without opening a schema.

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?

Gives explicit mode-selection guidance: omit check_id to survey recent checks, pass check_id to drill into a single check's pages, and notes page_status selects other page categories. It stops short of naming sibling alternatives (e.g. ragfeed_monitor_get) or stating when-not to call it, so it is clear context rather than full routing.

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