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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the description's extra value is the statement that results are computed server-side from live Fortnox data and aggregated over all pages — telling the agent no pagination handling is needed. It does not disclose failure modes or what happens when the fiscal year cannot be resolved; return details are arguably covered by the output schema.

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 is front-loaded in the first clause, followed by the example question and the data-source note — a sensible order. The text is dense and mixes Swedish with an English data-source sentence, but no sentence is redundant.

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 two-optional-parameter, read-only check with an output schema and full annotation coverage, the description supplies what the check verifies, the trigger question, and the data provenance. Remaining gaps (output shape, behavior on missing prior year) are offset by the output schema and annotations.

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% and both parameters (date, financialyear) are documented in the schema, so the schema carries the semantics. The description does not add syntax, default behavior, or precedence rules between date and financialyear, so the baseline 3 applies.

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 verification task: whether this year's opening balances match last year's closing balances, whether last year's result is booked and appropriated, and comparison against prior-year key figures. That is far more specific than the title 'Årsskiftet'. It does not explicitly position itself against siblings like get_year_end_package or reconcile_ledgers, so it stops short of a 5.

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 embedded example question ('Stämmer ingående balanserna med förra årets bokslut?') gives an agent a concrete trigger pattern for selecting this tool. There is no explicit when-not guidance or named alternative among the many sibling check_* tools, which keeps it at 4 rather than 5.

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