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

Annotations already cover readOnly/openWorld/idempotent/destructive, so the bar is lower, and the description still adds real context: no rate limit, a single optional parameter, and an explicit consistency guarantee that counts match vergabe_liste (same visibility gate, same stale-deadline exclusion). It does not describe the response shape, but the consistency and rate-limit notes are substantive additions beyond structured fields.

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-loaded with the core behavior (counts by portal and status) and then efficient supporting facts: consistency with vergabe_liste, no rate limit, parameter count. The example-questions block is slightly redundant with the opening sentence but earns its place as routing signal. No wasted 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?

No output schema exists, yet the description conveys what comes back (per-portal counts by status) plus the visibility/staleness semantics governing those counts, and annotations carry the safety profile. The only real gap is that the dead-portal handling is not explained in prose, but the referenced parameter and listed example questions cover most agent needs.

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 description coverage is 100% and the single parameter include_dead is fully documented there, establishing the baseline of 3. The description only says 'One optional parameter' without naming include_dead or adding meaning about what excluding dead-portal notices implies for the counts, so it neither compensates nor detracts.

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 and resource: per-portal notice counts broken down by status, explicitly listing example portals (TED EU, Vergabe-Bund). It carves out a distinct niche from siblings like vergabe_liste and vergabe_statistik by framing itself as a source-coverage breakdown, so an agent can differentiate without opening schemas.

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 example user questions ('Welche Vergabeportale sind in der Suche enthalten?', 'Woher kommen die Daten...') effectively tell the agent when this tool is the right answer. However, it never explicitly contrasts with vergabe_statistik, which is the closest sibling and the most likely mis-selection, so the routing guidance stops short of full exclusions.

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