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

With no annotations, the description carries the full load and does little: it does not say what the response looks like (date+name pairs? a list? a map?), whether coverage is Austria-wide or per-Bundesland, or how an invalid/out-of-range year is handled. For a lookup tool this is thin but not misleading.

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?

A single short sentence with no filler, and the key qualifier (Österreich, für ein Jahr) is front-loaded. It is efficient to the point of under-specification, but nothing in it is wasted.

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 one-parameter tool with no annotations and no output schema, the description should at minimum pin down the year format and the shape of the result; it does neither. An agent can guess, but the definition does not make it callable with confidence.

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 0% and the only parameter, 'jahr', is an untyped-in-description integer; the description's 'für ein Jahr' hints at the meaning but never states the expected format (e.g., 2025 vs. '25) or the valid range. The one piece of information a caller needs is missing from both schema and description.

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?

Names a specific resource (statutory Austrian public holidays) and a scope (one year), which is enough to tell it apart from schulferien at a glance since 'gesetzliche Feiertage' is not the same as school holidays. It stops short of naming a sibling explicitly, so it is clear but not fully differentiated.

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 statement of when to use this versus schulferien or the other siblings, and no prerequisites given. The only hint is the word 'gesetzliche', which a caller must infer as the dividing line from school holidays.

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

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

With no annotations at all, the description carries the full behavioral burden and discloses almost nothing: it does not say whether the result is a numeric amount, a legal citation, or a structured object, nor whether multiple thresholds (e.g. prior years, EU small-business scheme) are involved. The only behavioral hint is the jurisdiction/year scoping implied by 'AT 2026'.

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?

It is five words with zero redundancy, so nothing is wasted, but it is a fragment rather than a structured sentence and is under-specified rather than concise in a useful way. There is no front-loaded statement of what the tool returns.

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?

The tool has no annotations and no output schema, so the description is the only place an agent can learn what comes back — and it says nothing about return shape, units, currency, or whether the 2026 threshold is a single figure. For a zero-parameter lookup whose entire value is its answer, that is a significant omission.

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?

The tool takes zero parameters and the schema is empty at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-related gap exists.

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 is a German keyword string, not a verb+resource statement: it names the domain concept (Kleinunternehmergrenze), the tax type (Umsatzsteuer), the jurisdiction and the year (AT 2026). An agent can infer this is a lookup of the Austrian VAT small-business threshold, but the tool never states that it returns a value or what that value represents, so the purpose is only vague-inferable.

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 guidance and no mention of any sibling. The siblings (feiertage, schulferien, svs_werte, svs_schaetzung) are all Austrian data-lookup tools, so the only differentiation here is the topic keyword itself, which the agent must decode without help.

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

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

No annotations are provided, so the description carries the full burden. It adds useful context by naming the authoritative source ('bmb.gv.at') and the school-year scope ('2026/27'), but it does not explicitly state that the operation is read-only or describe the return format and error behavior.

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 description is a single front-loaded sentence with no wasted words. It efficiently states the resource, scope, and source.

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 simple two-parameter lookup with no output schema and no annotations, the description supplies key context (source and school year) but omits return-value details and usage guidance. It is minimally adequate but not fully complete.

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 0%, so the description should compensate for undocumented parameters. It mentions the state and school-year concepts, but those are already conveyed by the schema's property names, enum, and default; it adds little semantic detail about parameter formats, optionality, or expected values.

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 specific resource ('Schulferien') scoped per federal state ('je Bundesland') and school year ('Schuljahr 2026/27'), with a named source ('Quelle bmb.gv.at'). It does not explicitly distinguish itself from sibling tools such as 'feiertage', so it is clear but lacks sibling routing.

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 gives no when-to-use guidance, no exclusions, and no alternatives among siblings like 'feiertage'. It only identifies the data the tool returns, leaving the agent to infer when this tool is appropriate.

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

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

With no annotations, the description carries the burden and does disclose two behavioral traits: the result is 'grob' (approximate) and 'unverbindlich' (non-binding). It says nothing about side effects, permissions, or what the response contains, which is a meaningful gap for a zero-annotation tool.

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?

A single front-loaded sentence naming the estimate, the year, the input basis, and the caveat, with no filler.

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 simple one-parameter computation the essentials are present, but with no output schema the description could state what the estimate returns (a single contribution amount, a breakdown by branch). It also leaves unclear whether 'SVS' is the Austrian social insurance institution and which 2026 rates apply.

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 0%, so the description needs to compensate. It does identify the single parameter's meaning implicitly as the annual profit used as input, but adds no detail on whether it is gross/net or pre-tax profit, or the expected magnitude/units.

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 gives a specific verb (estimate) and resource (SVS-Beitragsschätzung 2026) plus the basis of the calculation (Jahresgewinn). It is clear what the tool computes, but it never distinguishes itself from the closely related sibling 'svs_werte' (actual values vs. estimate).

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 statement of when to use this estimate versus 'svs_werte', no prerequisites, and no exclusions. 'unverbindlich' is a liability caveat about accuracy, not guidance on tool selection.

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

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

No annotations are provided, so the description carries the full burden. It implies read-only reference data but never states that it takes no input, requires no auth, is static/offline, or how the values are structured in the response.

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?

A single terse phrase with zero waste and the key qualifier (2026) front-loaded. However, terseness here borders on under-specification rather than efficiency.

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 no output schema, the description must convey what comes back, and it partially does by enumerating the figure types. It still omits the shape of the result (per-year table, per-category values, units) and any behavioral notes, so an agent knows roughly what it gets but not the form.

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?

The tool takes zero parameters, so there is nothing to document; baseline 4 applies. The description does not introduce any parameters, which is consistent with the empty schema.

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 phrase "SVS/GSVG-Werte 2026" names a specific resource and the parenthetical lists the contained figures (Beitragssätze, Mindest-/Höchstbeitragsgrundlage), so the agent can infer it is a static reference lookup. But there is no verb and no explicit statement that this returns reference values rather than computing anything, leaving the purpose somewhat implicit.

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?

No guidance on when to use this versus the sibling svs_schaetzung, which plausibly covers estimation and would be the obvious alternative. The only cue is the parenthetical field list; there is no when/when-not statement.

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