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

Annotations already establish the safe-read profile (readOnlyHint, idempotentHint, non-destructive, openWorldHint=false), so the bar is lower. The description still adds real value by disclosing the rules year (2026), the last-updated date (2026-09-25), and the returned artifacts (result rows, raw engine outputs, sources with lastChecked dates, disclaimer), which an agent cannot infer from annotations.

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?

Purpose and scope are front-loaded, and the paragraph is dense but free of filler. The trailing sentences on return contents, freshness metadata and the page URL are all load-bearing, though the whole block is a single run-on paragraph that could be broken up.

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 15-parameter, single-required-field calculator with no output schema, the description supplies the missing pieces: it enumerates what is returned, states the rule-set year and freshness, and delimits the supported category. Only a minor gap remains around how partial/unknown inputs affect the returned duration, which the schema partially covers.

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% with 15 richly documented parameters including enums, ranges, defaults and cross-parameter conditions, so the schema carries the burden and the baseline is 3. The description's only added meaning is the meta-note that 'Only used when' inputs are conditionally needed, which summarizes gating already stated in each schema field.

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 the specific benefit (regular DYPA unemployment benefit), the population (common unemployed people in Greece), and the exact outputs it computes (daily/monthly amounts, dependant supplement, duration, deadlines, bonuses). It clearly scopes out construction, seasonal, seafarers and continuation categories. It does not explicitly name a sibling tool, so sibling differentiation rests on the country/benefit naming rather than prose.

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 description states which categories are in scope and that other categories are 'outside scope', which is a form of when-not guidance, and it flags that inputs marked 'Only used when' are conditionally required. However, it never routes the agent to an alternative tool for the excluded categories, so usage guidance is implied rather than explicit.

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