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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description still adds genuine operational context beyond them: rate limits (40 per 10 min, 300/day per IP), offset cap of 2000, cross-portal dedup semantics (same tender appears once per portal with different uids), and the `total`/`by_bundesland` counting behavior including the 500-notice threshold for the aggregation.

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 purpose, then usage, then data scale, then identifiers, then limits. The trailing sample questions are somewhat redundant with the earlier filtered-listing examples, so it is not perfectly lean, but nearly every sentence carries operational value.

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 16-parameter, zero-required-parameter read tool with no output schema, the description covers everything an agent needs: data volume (190k notices, 30k open), refresh cadence, paging/limit ceilings, aggregation fields, dedup rules, and how the returned ids chain into sibling tools.

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%, so the schema already documents all 16 parameters; baseline is 3. The description reinforces a few key ones (q is full text not semantic, cpv_prefix=72 for IT) but largely repeats schema content. Its one real addition is the cross-tool linkage — `id` feeds get_tender_documents and `uid` feeds get_tender — which is useful but does not extend to the majority of parameters.

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?

Opens with a specific verb and resource ('Lists German and EU public tender notices') and immediately names the filter dimensions that define the tool. It explicitly draws the line against search_tenders ('Search by topic or meaning is done by search_tenders'), so an agent can distinguish the two sibling tools without reading the 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?

States the intended use case ('structured listings') and names the alternative plus the condition that selects it (semantic/topic search → search_tenders). Concrete routing examples (cpv_prefix=72, Landkreis + 14-day deadline, newest publications) plus sample user questions make the invocation conditions unambiguous.

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