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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds one useful behavioral guarantee—'Never returns silently empty'—which goes beyond the annotations, but it does not elaborate on what the status response contains or how failures are signaled. The output schema partially covers this, so a 3 is appropriate.

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 two short sentences with no filler. The core purpose is stated first, and the non-empty guarantee is front-loaded as an additional behavioral point. Every word earns its place.

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 parameterless status tool with annotations and an output schema, the description covers the essential purpose and a key response property. It does not explicitly say 'call this to verify API availability before other requests', but that is optional given the tool name and sibling context.

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 has zero parameters and an empty input schema, so the schema fully documents the argument surface. The description correctly adds no parameter details; the baseline of 4 for zero-parameter tools 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 clearly identifies the tool as reporting the availability of the TERMDAT API, which is distinct from the sibling search/translate/list tools. It lacks an explicit verb like 'Check', but the noun-phrase 'Availability of' is unambiguous enough to separate it from siblings.

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 is given on when to call this tool versus alternatives, nor is there any hint that it should be used as a precondition for other API calls. The description provides no when/when-not framing, leaving the agent to infer usage from the name alone.

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?

Annotations already declare readOnlyHint and destructiveHint, so the safety profile is clear. The description adds useful behavior beyond structured data: each term is reported as one of three statuses, and lookups run concurrently. It does not mention authentication or rate limits, but the read-only annotation lowers the bar.

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?

Three sentences with no fluff: purpose first, then context, then behavioral details and limits. Every sentence adds information an agent needs.

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?

Given the simple 2-parameter schema, output schema presence, and read-only annotations, the description is nearly complete. The main missing piece is language parameter semantics, and explicit alternative routing would help, but these are not fatal for a basic check 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?

With 0% schema description coverage, the description must compensate for parameter meaning. It clarifies that 'terms' are a list and repeats the 25-term cap from the schema, but it does not explain the 'language' parameter, its accepted values, or how it affects the check. This is a clear gap.

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 action ('Check a list of terms against validated TERMDAT designations') and clarifies the exact QA use case. It is clearly distinct from siblings like search_terms, but it does not explicitly differentiate itself by naming any sibling tool.

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 provides strong when-to-use guidance: 'Intended for communication QA' and lists example content (authority names, department titles, abbreviations). It does not mention when not to use it or point to an alternative, so it stops short of full exclusion guidance.

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?

Annotations already mark it read-only and non-destructive; the description adds useful behavioral context beyond that: it works on previously discovered entries, returns full language variants, and can surface all four national-language designations. No contradiction with the 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?

Three sentences with no filler. The first sentence states the operation and scope, and the second/third give concrete usage guidance. The most important info is front-loaded.

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 ID-based lookup with an output schema and read-only annotations, the happy path is well covered: what to pass and why. The main gap is the optional language parameters, which are not explained and could affect the returned variants.

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 needed to compensate. It explains entry_ids ('numeric IDs', 'entry_id') and hints at language output, but never explains in_language or out_language, their defaults, or how they interact with the 'full language variants' behavior.

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?

Opens with 'Fetch known TERMDAT entries by their numeric IDs' – a specific verb, resource, and input identifier. The follow-up sentence explicitly positions it as the re-retrieval counterpart to search_terms, making it easy to distinguish from sibling tools.

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?

Provides clear use context: call this after search_terms, using the returned entry_id, to get all language designations at once. It does not explicitly state when not to use it or compare with translate_term/check_terms, so it falls short of a fully explicit routing rule.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds concrete context by asserting the list has exactly 23 items and provides an example, which is helpful but does not go beyond what annotations already establish about 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, tightly worded sentence that front-loads the verb and resource, includes a concrete example, and contains no filler or redundant information. It earns its place entirely.

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 read-only list tool with an output schema present, the description is mostly adequate. The main gap is the complete absence of explanation for the 'language' parameter, which is the only way to customize the call. Annotations cover safety and the output schema covers return values, so this is a moderate, not severe, 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?

Schema description coverage is 0% for the only parameter 'language', and the description does not mention it or explain how it affects the output (e.g., the language of classification labels). Since the schema is unhelpful and the description fails to compensate, the agent has no guidance on this parameter.

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 verb ('List') and resource ('subject classifications') and gives an example mapping ('BILD = education'), making the purpose immediately clear. It does not explicitly contrast with sibling tools, but the resource is unique enough that the tool is easily distinguished from the provided siblings.

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 phrase 'for classification_ids' implies that the tool returns classification IDs useful for other operations, giving a hint of when to use it. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives, leaving the agent to infer the usage context.

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?

The readOnlyHint and destructiveHint annotations already establish safety; the description adds a useful scale cue (~140 collections). It does not address behavior such as language filtering, ordering, or pagination, but with annotations present this is acceptable.

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 well-structured sentence that front-loads the action and resource, then gives the purpose. No wasted words.

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 read-only list operation with an output schema and safe annotations, the description is nearly sufficient. The only real gaps are the undocumented language parameter and lack of explicit differentiation from list_classifications.

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%, and the description does not explain the only parameter, language, at all. The schema's title and default provide minimal meaning, but the description fails to compensate for the low coverage, leaving the parameter's effect unclear.

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 specific action ('List') and resource ('TERMDAT collections') and states the downstream purpose ('use as collection_ids filters'). It does not explicitly distinguish the tool from the similarly named sibling list_classifications, so it falls 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?

'For use as collection_ids filters' gives a clear reason to invoke the tool, so an agent knows when the result is needed. However, it never says when not to use it or how it compares with alternatives such as list_classifications.

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?

The annotations already declare readOnlyHint and openWorldHint, and the description substantially enriches them with concrete behavioral details: Lucene wildcard/fuzzy syntax, whole-word matching, detail=False returning unusable empty variants, out_language being purely additive, and the API's deliberate deliberate subset limitation confirmed by the Federal Chancellery. This is far more transparent than the annotations alone.

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 longer than average, but every paragraph adds decision-relevant behavior, caveat, or parameter semantics. The core action is front-loaded, and the later sections are thematically grouped rather than rambling.

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?

Given an output schema exists, the description still provides everything else needed for correct invocation: query syntax, filtering behavior, retry policy, scope limitations, and precise open-world semantics. An agent could use this tool correctly and interpret empty results confidently without external help.

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 carries the full burden. It explains search_term's Lucene syntax, detail's effect on variants, out_language's additive nature, fields' comma-separated allowed values and default, and classification_ids/collection_ids narrowing — none of which is available from the schema itself. Even in_language and max_results need no explanation because their names and schema defaults are self-evident.

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 opens with a specific verb-plus-resource statement: 'Search TERMDAT for official designations of the Swiss Federal Administration.' It then specifies the concrete use case — looking up validated names of authorities, departments, or legal acts — and clarifies the administrative-nomenclature scope, distinguishing it from ordinary vocabulary lookup.

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?

It gives explicit when-to-use guidance ('before citing it') and strong when-not-to-use rules: retry with a wildcard before concluding absence, never invent a guessed designation, and keep detail=True unless you only need counts or classification filtering. It also points to list_classifications/list_collections as the narrowing alternatives and warns that not-found-in-API does not mean not-found-in-TERMDAT.

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?

Beyond the readOnly/openWorld/destructive annotations, the description discloses material behavior: matches only designation fields, never terms merely mentioned in definitions, returns the preferred designation plus accepted variants, and supports Lucene wildcards with a retry hint. These details genuinely help an agent predict results without calling the 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?

The description is front-loaded with the core function, then adds return behavior, use cases, matching semantics, and retry guidance. Every sentence earns its place and there is no repetition of schema or annotation information.

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?

Given the annotations, an output schema, and mostly self-descriptive parameters, the description covers the key behavioral edge cases an agent needs: what fields are matched, what is returned, and how to handle empty results. It does not spell out language code semantics or pagination details, but those are either self-evident or covered by the output schema.

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 carries the burden. It does add useful meaning for the term parameter by explaining Lucene wildcard support and the retry strategy, but it does not explain to_language, from_language, or max_results beyond what the schema's names and defaults already suggest. This is partial compensation, not full coverage.

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 opens with a specific verb and resource: 'Get the official equivalent of an administrative term in another national language.' It further narrows the tool's purpose by naming the concrete use cases (authority names, department titles, titles of legal acts), which clearly distinguishes it from sibling tools like search_terms or get_entries.

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?

It gives explicit context for when to use the tool: 'Use this for authority names, department titles and titles of legal acts.' It also provides practical guidance on handling empty results with term*, but it does not explicitly name alternatives or state when not to use this tool versus a sibling, so it falls just short of a 5.

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