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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered structurally. The description's added behavioral content is mostly a listing of returned fields plus the 'date it was checked' freshness cue, which is closer to return-format description that the output schema already carries; no auth, quota, or coverage-caveat information is added.

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?

One front-loaded sentence identifying the resource and its payload, followed by a short usage cue; nothing is wasted. The long comma-separated enumeration of topics is informative rather than padding, though it makes the sentence dense enough that the 'use it to cite or verify' cue could have come first for better prioritization.

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?

With an output schema present and rich annotations, the description need not explain return values or safety, and it covers purpose, payload and usage adequately. The remaining gap is that it does not state the default topic ('contributions') or that topic=all returns everything, which matters slightly for a zero-required-parameter tool.

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 baseline is 3, but the description adds genuine mapping value by naming the topic groups in natural language ('BVG', 'board and lodging', 'IV assistance contribution', 'Geneva au pair contract') that an agent can match against a user request to the enum values pension_bvg, in_kind_wage, iv_assistance and au_pair_geneva. The optional 'search' parameter is not mentioned in the description, but the schema documents it.

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 states a concrete resource — the federal and cantonal source documents behind Clino's figures, including URL, verbatim sentence and date checked — which is a distinct artifact from the sibling tools that return the figures themselves (get_minimum_wage, get_canton_rules). However, it never explicitly distinguishes itself from those siblings, and the enumerated category list (minimum wages, thresholds, etc.) overlaps their territory, so the separation requires inference.

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?

"Use it to cite or verify a number" gives a clear, actionable when-to-use condition tied to provenance/verification intent. It stops short of naming an alternative or an exclusion (e.g. 'use get_minimum_wage when you only need the value, not the source'), so it does not reach the top band.

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