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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. Beyond that, the description adds genuinely non-obvious behavior: results are scoped to the caller's team, profiles are 'live', empty lists and null bounds both mean a criterion is unset, and the response carries an exact total. It does not explain ordering of the returned profiles, which is the main remaining gap.

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?

The scoping statement comes first, which is good, but the core is a single run-on sentence with a long parenthetical stack of criteria that is hard to parse on one read. The field inventory earns its place, yet commas-and-parentheses phrasing makes it denser than it needs to be; a short bulleted or clause-per-sentence structure would read better at similar length.

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?

There is no output schema, so the description must carry the return shape — and it does, listing every field a profile exposes plus pagination and total semantics. Combined with the safety annotations, an agent has what it needs to call this correctly. The missing piece is ordering and whether paging is stable across calls.

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%: both limit and offset already carry defaults and maxima in the schema. The description's only addition is that the response carries the exact total, which is return-shape information rather than parameter meaning. Baseline 3 is right for parameters the schema fully documents.

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 names a concrete resource (the caller team's live tender profiles) and enumerates exactly what each profile contains: CPV codes, NUTS regions, EUR value band, keyword matching rules, procedure types, buyer legal types, notice kinds and minimum days to deadline. That is far more specific than the title. It stops short of 5 because it never states the operation plainly as a list/read and never distinguishes itself from tender_matches or tender_export_preview, which an agent must choose between.

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 or when-not-to-use guidance at all. Nothing tells the agent whether this is the right tool to inspect saved profile criteria versus pulling matched notices via tender_matches, nor are any prerequisites stated. The reader must infer suitability from the sibling names alone.

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