DRGSystem — German medical coding catalogs

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds meaningful behavioral context by explaining the focus/parents/items response structure and the no-code fallback to anatomical main groups.

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?

Two sentences convey the main response modes and the no-code fallback without filler. The core behavior is front-loaded and every clause adds relevant 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?

With annotations and an output schema present, the description does not need to re-explain safety or return values. It still covers the key response structure and the default no-code behavior, which is sufficient for a two-parameter read-only get 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%, and the schema already documents both the code and year parameters in detail. The description only restates the empty-code behavior and adds no further parameter semantics beyond what the schema provides.

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 the verb 'liefert' and the resource 'ATC-Kode' and explains the three response areas: 'focus', 'parents', and 'items'. It is clear what the tool returns, but it does not explicitly distinguish itself from the sibling atc_search 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?

It explains the useful default behavior that calling without a code returns the anatomical main groups. However, it gives no guidance on when to use atc_get versus atc_search, and no exclusions or prerequisites are stated.

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, idempotentHint and openWorldHint=false, covering the safety profile. The description adds that hits are returned in 'items' with DDD and assigned ICD codes, which is some useful return context, though the output schema already exists and covers return structure.

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?

Two tight sentences with no filler, and the core action and search key are front-loaded. Slightly more economy or routing information could have been packed into the second sentence about results.

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 that annotations cover the read-only/idempotent profile and an output schema exists for return values, the description supplies enough for correct invocation. It is only missing explicit routing to atc_get and any note on catalog/year behavior.

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 all three parameters (query, year, limit) are already documented with examples and defaults. The description only restates the query semantics ('Kode oder Wirkstoff') without adding format or interpretation beyond the schema, 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?

States a specific verb+resource (durchsucht die amtliche ATC-Klassifikation) and the two search keys (Kode oder Wirkstoff). It implicitly separates itself from atc_get by being a search, but never names the sibling or its complement.

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?

Usage is only implied: it says it searches by code or active ingredient, which suggests when to pick it over a lookup. There is no explicit when/when-not guidance and no mention of atc_get as the alternative for a known exact record.

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, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context about the returned fields, historical coverage since 2014, and data sources, though it does not discuss error cases or permissions.

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 purpose and then branches cleanly into behavior without and with a Länderkürzel. It is appropriately sized for a tool with this much output detail, though the sentences are dense and could be slightly tighter.

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 description is largely complete: it explains the tool's purpose, parameter-dependent output behavior, historical scope, and sources. Because an output schema exists, it need not document every return field, but it could be more complete by mentioning when to use this tool versus the search sibling.

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 both parameters are already documented in the input schema. The description reinforces what happens with and without the code parameter, but it adds little parameter-level detail beyond the schema and does not address the year parameter's 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?

The description states a specific verb and resource: it returns Basisfallwerte under § 10 KHEntgG and describes the exact output structure with and without a Länderkürzel. It is clear what the tool does, although it does not explicitly differentiate itself from the sibling basisfallwerte_search.

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 clearly explains how to use the optional code parameter: leaving it empty returns all 16 Bundesländer plus the federal value, while providing a Länderkürzel focuses the result on that state. It does not name alternatives or state when to use this tool instead of basisfallwerte_search, so it falls short of explicit when/when-not 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 declare readOnly/idempotent/closed-world, so the safety profile is covered; the description still adds real context by describing each item's fields (abrechenbarer Wert, Veränderung zum Vorjahr, Abstand zum Bund) and the 'bund' object with Korridor. It does not mention pagination or ordering, which is a minor gap for a capped 16-row result.

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, zero filler, with the lookup semantics front-loaded and the return shape and fallback following in order of importance. Nothing repeats the schema verbatim.

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?

An output schema exists, yet the description still usefully names the returned fields and the whitelist-style fallback, which is the main surprising behavior. Only the absence of any cross-reference to the *_get sibling keeps it from being 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 100% and each parameter is already documented there, including the 'limit is ignored' note. The description reinforces the query semantics with examples ('Bayern', 'NW') but adds no format or constraint information beyond the schema, 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?

States a specific verb and resource ('Sucht den Landesbasisfallwert eines Bundeslandes') plus the query form (Name oder Kürzel mit Beispielen). The search-vs-get split against the sibling basisfallwerte_get is implied by the query-based lookup but never made explicit.

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?

Explains the fallback behavior ('Passt kein Land, stehen alle 16 in items'), which tells the agent what happens on a miss, but gives no explicit guidance on when this tool should be chosen over basisfallwerte_get or how to treat the year parameter beyond the schema note.

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, idempotentHint and openWorldHint=false, so the safety profile needs no restatement. The description adds one genuine behavioral trait: the no-code invocation returns the top-level outline. The rest of the text merely restates the shape of response fields, which the output schema already carries.

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 two sentences with no filler; the response-field mapping comes first and then the fallback behavior. The only weakness is that the fallback condition repeats an existing schema hint, so it earns slightly less than full marks.

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?

Because an output schema and annotations are present, the definition carries the full behavioral profile, and it does so adequately for a two-parameter read tool. There is a small gap in workflow guidance: it does not tell the agent to call dkr_search first if the code is unknown.

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 both parameters, including the recommended default for 'year', are already documented in the schema. The description only repeats that omitting the code yields the top level, which the schema's 'code' description says verbatim. The baseline of 3 fits.

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 verb and resource: it delivers the full text of a Kodierrichtlinie, broken into 'focus', 'parents' and 'items'. An agent can tell this apart from dkr_search by the verb pattern, but the description never names the sibling search tool or states the difference explicitly.

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?

Usage context is implied rather than stated: calling without a number returns the top-level outline, which tells the agent about one calling mode. There is no guidance on when to use dkr_get instead of dkr_search or dkr_psych_get, and no note on how to obtain a DKR number in the first place.

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 readOnly/idempotent/closed-world, so the safety profile is covered. The description adds real value by disclosing the shape of the response (full text in 'focus', classification in 'parents', child sections in 'items') and the list fallback when no code is given.

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?

Two short sentences, no filler, with the return-structure detail first and the no-argument behavior second. Every clause carries 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?

With annotations, a full output schema, and 100% parameter coverage, the description only needs to orient the agent — which it does. The one gap is that it doesn't point to dkr_psych_search for discovering codes, which matters in a 40-tool catalogue.

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% and the 'year' parameter already carries an unusually thorough explanation of the latest-version fallback. The description only reinforces the 'code' semantics via 'Ohne Nummer aufgerufen', adding nothing the schema doesn't already say, 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?

Names a specific verb+resource (retrieves a DKR-Psych guideline) and even enumerates the response slots ('focus', 'parents', 'items'), plus the no-code list mode. It never names the sibling dkr_psych_search, so the get-vs-search split is only inferable from the naming convention.

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 does state one concrete usage branch: calling without a number returns the guideline list. It gives no explicit routing to dkr_psych_search for finding a code, and no when-not-to-use guidance beyond that single clause.

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 readOnly, idempotent and closed-world, so safety is covered. The description adds genuinely useful behavior: hits land in 'items' and already contain the full guideline text, telling the agent no follow-up get call is needed. It does not discuss ranking or how number vs. text matching behaves.

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 short sentences, front-loaded with the search action, followed by applicability context and a return-value note. Every sentence carries information an agent cannot get from the structured fields.

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, full annotation coverage and 100% schema coverage, the description needs only purpose and routing context, which it provides, plus the useful note that full text is embedded in results. The remaining gap is the unstated relationship to dkr_psych_get/dkr_search.

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%, so the schema fully documents query, year and limit. The description only restates the query semantics ("nach Nummer oder Text") already present in the schema and adds nothing about year defaults or limit behavior, so 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?

States a specific verb ("Durchsucht") and a precisely scoped resource (DKR-Psych, Psychiatrie/Psychosomatik) with the two search modes (Nummer oder Text). The scope implicitly separates it from dkr_search (general DKR) and dkr_psych_get, but no sibling is named explicitly.

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 PEPP/§ 17d KHG sentence explains domain applicability (when these rules apply instead of the DKR), not when to pick this tool over dkr_search or dkr_psych_get. Usage is only implied by the resource scope; there are no explicit alternatives or exclusions.

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 readOnly/idempotent/closed-world, so the safety profile is covered. The description adds genuinely useful behavior: results land in 'items' and already contain the full text of each guideline, which tells an agent it need not chain into dkr_get. Rate limits or year-fallback behavior are not restated, but the schema handles the default.

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?

Two sentences, zero filler: the search scope comes first, followed by the practically important note about where hits appear and what they contain. Nothing repeats the title unnecessarily.

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 full parameter documentation, the description only needs to convey scope and the form of results, which it does. The remaining gap is sibling disambiguation (dkr_get, dkr_psych_search), a minor omission for a read-only search 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 query, year and limit are all documented in the schema itself. The description's 'Nummer oder Text' echoes the query parameter without adding format or syntax detail beyond it, 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?

States a specific verb (durchsucht) and resource (DKR) plus the two supported lookup modes (Nummer oder Text), which lets an agent recognize this as a search tool. It does not distinguish itself from the sibling dkr_psych_search or explain the relationship to dkr_get, so the boundary between siblings stays 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?

Use is implied by 'durchsucht ... nach Nummer oder Text', so an agent can infer this is the lookup tool. There is no explicit when-to-use vs. dkr_get (fetch a specific guideline) or dkr_psych_search (psychiatry-specific guidelines), and no guidance on year 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?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds real value beyond them by enumerating the returned content: Bewertungsrelationen, Verweildauergrenzen with surcharges/discounts, Pflegeerlös, transfer/readmission flags, full-text footnotes, and co-billable Zusatzentgelte. It also discloses the no-code fallback 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?

Two dense but well-ordered sentences: content scope first, fallback behavior last. The long parenthetical field list is information-bearing rather than padding, though it is heavy.

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?

An output schema exists, so return values needn't be explained, yet the description still tells the agent what to expect and what happens without a code. Nothing needed to invoke it correctly is missing.

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 are documented in the schema, including the year fallback and code format, so the schema does the work. The description's no-code behavior note overlaps with the code parameter's schema text rather than adding new semantics.

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 (liefert/retrieves) and a precise resource scope: everything the Fallpauschalenkatalog discloses for a DRG, enumerated field by field. It does not name the sibling drg_search, so the boundary between get and search is only implied by the 'call without a code' behavior.

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 explains one important usage mode — omit the code to get the top catalog level (MDC) — but gives no explicit when-to-use/when-not and never points to drg_search for discovering codes. Usage is inferable, not stated.

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 readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuine behavioural context beyond that: results land in 'items' and carry only the partition, leading Bewertungsrelation, mean length of stay and boundary lengths of stay, with the full annex values deferred to drg_get — an important scope distinction for interpreting results.

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 tight sentences: purpose first, result shape second, sibling routing last. Nothing is redundant and the most decision-relevant information 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 three-parameter search tool with full schema coverage, an output schema and rich annotations, the description covers purpose, result contents and the get-vs-search split. Only minor gaps remain, such as how the default year is resolved or how many hits to expect, both of which the schema largely handles.

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 year, limit and query are already documented with examples and defaults. The description only restates that query accepts a code or a label, adding nothing about the year or limit semantics. Baseline 3 is appropriate.

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 and resource ('Durchsucht den Fallpauschalenkatalog (G-DRG)') plus the search axis ('nach Kode oder Bezeichnung'). It also names the sibling drg_get and what that sibling is for, so an agent can separate search from retrieval without opening a schema.

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 a clear routing rule: use this tool for lookup by code or label, and use drg_get when complete values across all annexes are needed. There is no explicit exclusion statement (e.g. when not to search, or behaviour when a query matches many DRGs), so it stops short of a full when/when-not treatment.

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 readOnly/idempotent/closed-world, so the safety profile is covered. The description goes further by disclosing the pricing formula (Bewertungsrelation × Basisentgeltwert), the billing context relative to PEPP Annexes 1a/2a, and the fallback to the catalog's top level without a code — meaningful context beyond structured fields.

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 response structure is front-loaded ('in focus … in items …'), followed by the formula and then the no-code rule. Dense but every clause carries information; the legal citation could be trimmed but is not wasteful.

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?

An output schema exists, yet the description still characterizes both response sections and the derived price semantics, which is more than required. The only missing piece for a catalog getter paired with et_search is a pointer to the search tool for unknown codes.

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 are fully documented there, including the recommended omission of 'year'. The description reinforces the no-code case but adds essentially no syntax or format detail not already in the schema, 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 specific verb ('Liefert') and resource ('ergänzendes Tagesentgelt' / ETD) and even describes the shape of the response ('focus' vs 'items'). It never names the sibling et_search, so differentiation from the search tool is left implicit rather than stated.

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?

Usage is implied through the closing clause 'Ohne Kode die oberste Ebene des Katalogs', which tells the agent how to browse the catalog. However, there is no explicit guidance such as 'wenn der Kode unbekannt ist, nutze et_search' and no statement about when a specific year should be requested (that lives only in the schema).

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, idempotentHint=true and openWorldHint=false, so safety behavior is covered. The description adds real value by saying hits are returned in 'items' with the daily valuation ratio or its range plus OPS codes, but it says nothing about empty-result behavior or year fallback beyond what the schema states.

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?

Two sentences, front-loaded with the scope-defining phrase and with zero filler. Slightly dense in the first sentence with parenthetical abbreviations, but nothing 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?

With an output schema present, the description needn't explain return values, and it still gestures at the result fields. Scope, domain and search keys are all covered; the only omission is explicit routing relative to et_get.

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% and each of the three parameters (query, year, limit) is documented with examples and defaults in the schema itself. The description adds no parameter-level detail beyond restating that search is by Kode oder Leistung, so 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?

Names a specific verb (durchsucht) and a precisely scoped resource (ergänzende Tagesentgelte des PEPP-Entgeltkatalogs, Psychiatrie/Psychosomatik, seit 2015) plus the two search keys (Kode oder Leistung). It does not explicitly distinguish itself from the sibling et_get, so the agent must infer search-vs-fetch itself.

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 implies usage (search when you have an ET code or a service name) and states the catalog's temporal coverage, which helps scope expectations. It never states when-not to use it or points to et_get/pepp_search as alternatives, leaving routing to inference.

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, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds genuine substance beyond that — the exact formula (Punktzahl × 5,82873 Cent × Steigerungssatz), per-line cent rounding, the default 'Ohne Satz wird die Schwelle angesetzt', the Begründungspflicht thresholds (2,3/1,8/1,15), and the § 6a reductions (25 %, 15 %, except Zuschlag J). It does not cover failure modes, but the return contract is 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?

The core purpose is front-loaded in the first clause, and nearly every phrase carries regulatory information, so it is not padded. However, the body is one sprawling sentence of formula jargon with no separation of concepts, making it hard for an agent to parse quickly.

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 complex, rule-heavy calculation tool with an output schema, 100% parameter coverage and readOnly/idempotent annotations, the description supplies enough domain context to invoke it correctly (formula, rounding, caps, reductions, defaults). Missing only routing guidance to/from the sibling tools.

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. The description does add some meaning — the enumeration of tarife (with § references) and the rule that an omitted Steigerungssatz defaults to the Schwelle or the tarif's Höchstsatz — but this largely restates what the schema's 'factor' and 'tarif' descriptions already say.

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?

States a specific verb and resource ('Berechnet eine Privatrechnung nach GOÄ') and names the domain rules it applies (Steigerungssatz, Höchstsätze je Tarif, Minderung § 6a). An agent can tell it apart from the goae_lookup/goae_search siblings, which retrieve rather than compute. It stops short of explicitly contrasting itself with goae_check_combination despite overlapping functionality.

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 explicit statement of when to use this tool versus goae_lookup, goae_search, or the sibling goae_check_combination. The clause 'Prüft zugleich die Kombination' hints at overlap with goae_check_combination but never tells the agent which to prefer. Usage must be inferred entirely from the tool name and domain knowledge.

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 establish readOnly=true, idempotent=true, openWorld=false. The description adds genuine behavioral context beyond that: every message states the rule verbatim with its source location, and it disclaims legal advice and individual-case review. It does not mention result format details, but the output schema covers returns.

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 rule taxonomy and disclaimers. It is dense but each segment (rule classes, verbatim citation behavior, disclaimers) carries distinct value; only the list of example numbers borders on exhaustive detail.

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, the description needn't describe return values, and it appropriately describes what messages contain ('nennt die Regel im Wortlaut und ihre Fundstelle'). It covers rule categories and scope limitations, leaving only minor gaps around which tool to use for adjacent needs.

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%, so both parameters (nummern, daten) are already documented in the schema, including the repeated-number and date-alignment semantics. The description adds no additional parameter-level meaning, so the baseline of 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?

States a specific verb and resource: it checks whether GOÄ numbers may be billed alongside one another per the GOÄ wording. It enumerates the exact rule classes it evaluates (exclusions, 'nur neben', frequency limits, surcharges), which sharply distinguishes it from sibling tools like goae_calculate and goae_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?

The description makes the applicable scope clear (combination/billing-side-by-side checks) and sets boundaries with 'Keine Rechtsberatung, keine Prüfung des Einzelfalls'. It does not explicitly route to a specific sibling (e.g. use goae_calculate for fee amounts), so it gives context but not full when/when-not routing.

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, idempotentHint and openWorldHint=false, so the safe-read profile is covered. The description's value-add is the enumeration of returned content, which largely duplicates the existing output schema rather than disclosing new behavioral traits (auth, rate limits, failure modes).

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 sprawling sentence packs a long catalogue of return fields (legend, points, tariffs, rules, interpretations, judgments, subsidy notes). Since an output schema exists, this enumeration is mostly redundant bloat rather than front-loaded signal.

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 single-id lookup with a full output schema and read-only annotations, the definition covers everything an agent needs to invoke it correctly. Only the missing routing guidance against goae_search keeps it short of a 5.

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 the schema already documents the 'nr' format with concrete examples ('3', '250a', 'K1', '3541.H'). The description adds no further parameter meaning, so the baseline 3 for schema-driven params 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?

States a specific verb ("Liefert") and resource (a GOÄ number) plus the scope of what is returned, so an agent can tell it apart from goae_search or goae_calculate. It does not name those siblings explicitly, so sibling differentiation is left to the naming convention.

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?

Usage is only implied: fetch one GOÄ number by its identifier. There is no explicit statement of when to use this versus goae_search (free-text lookup) or goae_calculate, and no preconditions or exclusions are given.

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, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: what the result rows contain (Nummer, Legende, Punktzahl, drei Gebührenstufen) and the comma-list semantic that returns exactly the listed numbers. It stops short of describing ordering or pagination 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?

Two front-loaded sentences with no preamble; the core purpose leads and the return format and multi-number behavior follow. The four inline query examples are slightly heavy but do real work illustrating the search syntax.

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, the description need not detail return structures, and it already summarizes them. Combined with full schema coverage and read-only annotations, an agent has enough to call the tool correctly; only sibling differentiation from goae_lookup is missing.

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%, so the baseline is 3, but the description adds meaning the schema lacks: that an exact comma-separated number list ('1, 5, 250') is resolved to precisely those entries rather than matched fuzzily. The limit parameter is left entirely to the schema, which is acceptable given its existing 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?

The description states a specific verb (Sucht/durchsuchen) and resource (Gebührenverzeichnis der GOÄ) plus the two search axes: Nummer or Worte der Leistungslegende. It is immediately clear what the tool returns. However, it never distinguishes itself from the sibling goae_lookup, which an agent could easily confuse with a search-by-number call.

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?

Usage is only implied through example queries ('Beratung', 'Sonographie Abdomen') and the comma-list hint. There is no explicit guidance on when to prefer this over goae_lookup or goae_calculate, nor any stated exclusions, so the agent must infer routing.

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 establish this as a pure read-only, idempotent, closed-world calculation. The description adds genuinely useful behavioral context beyond that: the DM-to-Euro conversion rate (1.95583), the two regulatory regimes and their thresholds, and proportional sharing across patients in one household. For a calculator with no side effects, this is solid additional disclosure.

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 a single dense, run-on sentence packing thresholds, regulations, exchange rate, and patient logic into one breath. There is essentially no filler, but the wall-of-text structure hurts readability and front-loading beyond the opening clause. Conciseness is good; structure is weak.

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 calculator with an output schema already present, the description need not explain return values. It covers the domain rules and input regimes thoroughly, giving the agent enough to invoke it correctly. The main missing piece is explicit routing against sibling tools.

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 schema already documents km, nacht, patienten, gefahreneKm, and abwesenheitStunden. The description reinforces the semantics (night window 20–8, proportional split for multiple patients, over-25 km behavior) but largely restates what the schema already provides, so 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 specific resource and computation domain: Wegegeld (travel fee) per § 8 GOÄ and Reiseentschädigung per § 9 GOÄ, computed in Euro. This distinguishes it from general siblings like goae_calculate, since it is scoped to travel allowance specifically. The verb is implied by the title (berechnen) rather than restated, but the purpose is unmistakable.

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 reveals the internal branching logic (≤25 km uses § 8 radius rules; >25 km uses § 9 per-km/absence/overnight rules), which implicitly tells the agent how inputs map to regimes. However, it never explicitly states when to call this tool versus goae_calculate or the other goae_* siblings, so usage is inferred rather than directed.

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, idempotentHint and openWorldHint=false, and the description usefully adds the missing behavioral caveat: which Hybrid-DRG a case receives is decided by a certified grouper, not by this tool. It also discloses the data content and source citations ('und die Quellen'), which goes beyond the structured hints.

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?

Content is front-loaded into one dense sentence that enumerates returns, followed by two short clarifying sentences. It is long but nearly every clause carries information an agent needs; only the 'focus'/'jahr' framing is less than transparent.

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, return values need not be specified, yet the description still characterizes them, and annotations cover the safety profile. For a two-parameter read tool the only minor gap is the absence of any sibling comparison.

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 the schema already explains both parameters in detail, including the recommended empty-year behavior and the fallback to the latest available Fassung. The description's 'in focus' / 'in jahr' phrasing is ambiguous and adds little on top of what the schema states.

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 verb ('Liefert') and resource (Hybrid-DRG) and enumerates exactly what a lookup returns: Fallpauschale, Basis-DRG with Bewertungsrelation, OPS codes and their historical progression, plus the Abrechnungsregel. It never names the sibling hybrid_drg_search, so the distinction between retrieving one DRG versus searching is left to the reader.

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?

'Ohne Kode alle Hybrid-DRG des Jahres' clarifies the empty-code case, and the closing sentence correctly warns that this tool does not perform grouping. However, there is no explicit routing to hybrid_drg_search or to drg_get, so when to prefer this over its siblings is only implied.

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?

Die Annotationen decken bereits readOnly, idempotent und openWorld=false ab. Die Beschreibung ergänzt die Trefferstruktur ('items' mit Fallpauschale in Euro, Leistungsbereich, Basis-DRG) und den Katalogjahr-Kontext 2024–2027. Da ein Output-Schema existiert, ist die Feldbeschreibung weitgehend redundant; Verhalten bei null Treffern, Treffer-Reihenfolge oder Match-Logik (exakt vs. Teilstring) bleiben unerwähnt.

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?

Drei kurze Sätze, vorne die Kernfunktion, danach Trefferformat und Abgrenzung – kein Füllmaterial, jede Aussage trägt 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?

Für ein Suchwerkzeug mit Output-Schema, dichten Annotationen und voll dokumentierten Parametern ist die Beschreibung ausreichend: Rechtsgrundlage, Jahresbereich und Trefferfelder sind genannt. Offen bleibt das Verhalten bei leeren Ergebnissen und die Frage, wann hybrid_drg_get statt dieser Suche zu nutzen ist.

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?

Die Schema-Abdeckung liegt bei 100 %, alle drei Parameter sind im Schema ausführlich dokumentiert (Jahresbereich, Limit 1–100, Suchbegriff). Die Beschreibung wiederholt im Wesentlichen die Beispiele für 'query' und fügt keine zusätzliche Semantik zu Jahr oder Limit hinzu – Baseline 3.

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?

Der Satz nennt ein klares Verb (durchsucht) und eine klar abgegrenzte Ressource (Hybrid-DRG nach § 115f SGB V) sowie die Suchachsen Kode und Leistung. Es wird ein relevanter Nachbar (ops_get) für eine verwandte Frage benannt, aber die Abgrenzung zum nächsten Such-Geschwister hybrid_drg_get fehlt.

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?

Es gibt eine explizite Weiterleitung: die Frage 'steht ein OPS-Kode im Leistungskatalog?' gehört zu ops_get, nicht hierher. Ein Wann-nicht bzw. eine Abgrenzung zu hybrid_drg_get (Einzelabruf) oder drg_search (normale DRG) fehlt jedoch.

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 idempotentHint=true, so the description doesn't need to repeat those. The description adds behavioral details: it returns all entries from the alphabetical index that point to a code, including primary, star, and additional key numbers, and explicitly calls it a 'reverse lookup.' This goes beyond 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?

Two sentences, one German and one English, with the main action front-loaded and no unnecessary words. The bilingual note is helpful for international users without adding bulk.

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 tool with an output schema, the description covers the purpose, what it returns, and the scope of key types. It lacks explicit mention of error handling or pagination, but these are likely covered by the output schema or annotations. Overall, it is sufficiently complete for an agent to call it correctly.

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% – both parameters have clear descriptions in the schema (e.g., code format and year default). The tool description adds overall context about the reverse lookup purpose but doesn't add per-parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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 (liefert) and resource (Alphabetischen Verzeichnisses entries) and clearly differentiates from siblings: it is a reverse lookup by ICD code, distinct from icd10alpha_search (which searches by term) and from icd10_get (which retrieves code details). It also specifies the scope of key types considered (primary, star, additional, and second primary).

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 a clear use case: 'useful to see which clinical and everyday diagnosis terms a code covers.' This implies when to use it (when you have a code and need its terms). However, it does not explicitly mention alternatives like icd10alpha_search or state when not to use it, so it lacks an explicit exclusion.

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 cover read-only and idempotent behavior. The description adds that results include primary, asterisk, and additional keys with official titles from the systematic index, which is valuable context beyond the annotations. No contradictions.

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 bilingual, with German and English sections. It is front-loaded with the main purpose and includes practical examples. Though slightly repetitive across languages, it is well-structured and each part adds value.

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 output schema exists to describe return values, the description covers purpose, usage, alternatives, and parameter nuances. Nothing critical is missing for an agent to correctly select and invoke this 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 coverage is 100%, so parameters are documented. The description adds semantic guidance that query should be in German and provides examples like 'Herz' and 'Diabetes', plus advice to translate user terms first. This goes beyond the schema's basic descriptions.

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 states the tool searches the ICD-10-GM Alphabetical Index, mapping clinical and colloquial diagnosis terms to codes. It names the specific resource and differentiates from siblings icd10_search and icd10_get, making it unambiguous which tool to use for text-based searches.

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?

Explicitly states when to use this tool (natural-language diagnosis search, partial terms) and when to use alternatives (icd10_search for known codes, icd10_get for full entries). This provides clear routing guidance with no ambiguity.

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 cover safety (readOnly, idempotent, closed world), yet the description adds genuinely non-obvious behavior: statistics and stay carry their own data year that is older than the catalog year, and retired codes are still resolvable via the default year with the resolved year reported in the response. That is context an agent could not infer from the structured fields.

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?

Front-loaded with the returned data sections, then usage, with zero filler — but the full German/English duplication makes it roughly twice as long as needed and the enumeration of sections is dense. Every sentence earns its place; the bilingual mirroring does not.

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?

An output schema exists, so return values need not be explained, yet the description's section names (focus/statistics/stay/parents/items) match the response shape and tell the agent what to look for. Combined with the default-year and catalog-traversal behavior, nothing needed to call it correctly is missing.

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 the schema already documents normalization ('E110' vs 'E11.0'), the empty-code behavior and the year default with the same 'latest edition containing the code' rationale. The description restates these semantics rather than adding new parameter-level detail, 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?

Names a specific verb+resource ('Liefert alle Angaben zu einem ICD-10-GM-Kode') and enumerates the content buckets (focus/statistics/stay/parents/items), which differentiates it from icd10_search and icd10alpha_get. The English restatement makes the scope unambiguous.

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?

Explicitly routes the agent: 'Call it after a search to inspect a hit; call it without a code to browse the catalog from the top.' It also states the year parameter should only be set when a specific edition is required, and that omitting it yields the newest edition containing the code — a concrete when/when-not 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 cover the safety profile (readOnly, idempotent, closed-world), yet the description adds real operational insight: results are a flat but ordered list where 'isGroupHeader' rows are rubrics and only rows sharing the groupCode of a code are codable, plus the meaning of 'statistics' as a prevalence gauge. Much of this overlaps with the existing output schema, which keeps it from a 5, but the grouping/codability rule is interpretive guidance annotations cannot express.

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 routing are front-loaded in the first sentence, and the result-shape explanation follows logically. The full German/English duplication makes it longer than necessary, though the density of useful content keeps waste moderate.

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 three-parameter search with full schema coverage, annotations, and an output schema, this description covers the remaining gaps: what inputs are acceptable, how the flat result list must be read, and which sibling to call next. Nothing an agent needs to invoke it correctly is missing.

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 schema already documents query, year and limit, including formats and ranges. The description reinforces that query accepts both codes and free text but adds no syntax or default details beyond the schema, so the baseline of 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?

States a specific verb and resource ('Durchsucht den ICD-10-GM') and immediately defines its scope as the entry point for every diagnosis search, including the kinds of inputs accepted. It distinguishes itself from icd10_get by naming that sibling for a different task, so an agent can route without opening either schema.

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?

Explicitly says what goes here (codes, clinical terms, colloquial wording, abbreviations, typos, symptom paraphrases with concrete examples) and names the follow-up tool icd10_get with the exact conditions that select it (Inklusiva, Exklusiva, Kodierhinweise, Morbi-RSA, ATC). Almost nothing is left to inference.

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 cover read-only, idempotent and closed-world behavior, but the description adds real context they cannot: the provenance of address/beds/locations from the Krankenhausverzeichnis, the name-based IK mapping ('zuordnung'), and the explicit degradation when the mapping is 'Keine' (those fields are absent). What it does not cover is error behavior for an unknown IK or a code that exists only in older catalog years.

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 field list is front-loaded, followed by provenance and then the three calling modes, so the most decision-relevant information comes first. It runs long and the field enumeration is partly redundant with the output schema, but no sentence is 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?

With an output schema present, the description need not enumerate return fields, yet doing so plus documenting provenance and missing-value behavior makes the tool usable without opening the schema. The one remaining gap is the absence of any pointer to kh_search for discovery, which matters given how many sibling tools exist.

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%, so the baseline is 3; the description merely reinforces the hierarchy encoded in 'code' (Länderschlüssel example '05', empty for Bundesländer). The year-fallback rule ('jüngste Fassung, in der es den Kode gibt') is already fully stated in the schema and is not elaborated on further.

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 verb and resource: it returns the complete record for a single hospital ('vollständigen Angaben zu einem Krankenhaus') and enumerates the returned fields. The contrast with kh_search is only implied by 'vollständigen', not stated explicitly, so an agent must infer that this is the detail-lookup counterpart to the search 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?

It explains the three calling modes well: no code returns the Bundesländer, a two-digit Länderschlüssel (e.g. '05') returns that state's hospitals, and an IK returns one hospital. It never names kh_search or states when to prefer discovery-by-search over this direct lookup, so the alternative routing is left implicit.

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, idempotentHint and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only the result container name ('items'), which the output schema already provides, and the complementarity with kh_get. It says nothing about match behaviour (fuzzy vs. exact), sort order, or how the year parameter affects the result set.

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?

Two sentences, zero filler, and the search scope is front-loaded before the pointer to the follow-up tool. Every clause carries 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?

With annotations, a full input schema and an output schema present, the definition covers what an agent needs to select and invoke the tool. The only residual gap is describing what counts as a match and how the optional catalog year changes the result, which the description leaves entirely to the 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 100%, so parameter meaning is already fully documented, including the year and limit semantics. The description restates the query options (IK, Name, Ort) with example values but adds no syntax or behavioural detail beyond the schema, which is the expected baseline.

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?

States a specific verb and resource ('Durchsucht das Krankenhausverzeichnis') plus the three searchable fields (IK, Name, Ort). It also distinguishes itself from the sibling kh_get by assigning address and contact details to that tool, so an agent can choose between them without opening a schema.

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 second sentence establishes the division of labour: this tool finds the hospitals, kh_get retrieves address and contact data for a single house. That is clear routing guidance, though it does not state any explicit exclusion (e.g. that kh_get needs an IK from this result) or behaviour when a query matches nothing.

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, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: references between Leistungsgruppen are resolved in both directions, and calling without a code returns the highest hierarchy level. It does not discuss permissions or rate limits, but for a read-only retrieval tool the added behavioral detail is solid.

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 three sentences and contains no filler. It front-loads the main purpose and then adds the structural and no-code behaviour. The first sentence is dense but still readable.

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 output schema exists and the annotations carry the read-only/idempotent profile, the description is mostly complete: it explains the return grouping and the no-code fallback. The main missing piece is explicit routing against sibling tools, especially lg_search, which would help an agent choose this tool confidently.

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 both parameters are already well documented in the schema, including the meaning of leaving code empty and the behaviour of year. The description duplicates the no-code behaviour but adds no parameter semantics beyond the schema, which matches the baseline 3 for high-coverage schemas.

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 and resource: it returns a Leistungsgruppe under § 135e SGB V with all quality criteria and subrequirements. It clearly explains the structure of the returned object. It does not explicitly distinguish itself from the sibling lg_search, so a 4 rather than a 5 is appropriate.

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 implies usage by explaining that calling without a code returns the top hierarchy level, which is useful for catalogue retrieval. However, it does not state when to use this tool instead of alternatives such as lg_search, and it does not explicitly name any sibling or exclusion case.

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 idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context: it states that calling without a code returns all codes of the year that have published structural features, and that results include the decomposed conditions. This goes beyond 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?

Two sentences both carry essential information: the first defines the main purpose, the second clarifies the optional no-code behavior. No filler or redundant restatement of the tool name/title.

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 read-only tool with two optional parameters, an output schema, and full schema descriptions, the description is complete enough for an agent to invoke it correctly. It covers the main behavior, the optional argument semantics, and the read-only/idempotent nature via 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 description coverage is 100%, so the parameters are already fully documented. The description adds the contextual behavior that omitting the code returns all codes of the year, but it does not add new parameter-level meaning beyond what the input schema already provides.

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 states the tool's purpose: it returns OPS structural features checked by the Medical Service for an OPS code, including the conditions into which they are decomposed. The legal reference and the explicit resource ('Strukturmerkmale') distinguish it from the sibling get/search tools even without naming them.

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 implies when to use the tool: when you need OPS structural features and their conditions. It also explains the no-code behavior, but does not explicitly compare with alternatives such as lg_get or lg_search or state when not to use it.

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 idempotentHint, so the safety profile is covered. The description adds meaningful context by naming the searchable fields and noting that results appear in 'items'. It does not cover pagination, auth, or rate limits, but with an output schema and safe annotations this is adequate though not exhaustive.

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 compact sentences that front-load the core search scope and then add a valuable reverse-search use case. Every sentence earns its place, and there is no redundant restatement of schema fields.

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 read-only search tool with annotations and an output schema, the description covers what is searched, the reverse-query value, and result placement. It does not discuss matching semantics such as partial vs full text or pagination behavior, but the schema's limit/year definitions and the search scenarios make it sufficiently complete for correct invocation.

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%, but the description adds real semantics for the query parameter by explaining that it can be a number, name, or keyword from quality criteria and by giving concrete examples like 'Endoprothetik' and 'Stroke Unit'. This goes beyond the schema's generic 'Suchbegriff' description; limit and year are adequately left to the 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 description states a specific verb and resource: it searches Leistungsgruppen under § 135e SGB V by number, name, and quality-criteria wording. It also clarifies a reverse-search capability, making the purpose distinctive and unambiguous. The search scope is concrete enough that an agent understands exactly what the tool operates on.

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 clear search use cases, including the reverse question of which Leistungsgruppen require a specific Voraussetzung, so an agent can tell when this search tool is appropriate. It does not explicitly name sibling alternatives such as lg_get or lg_ops_strukturmerkmale or state when not to use it, but the context is strong enough for typical search-vs-get decisions.

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, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations: it covers all alphabet entries, considers both Schlüsselnummernfelder, and emphasizes exhaustiveness with 'alle' and 'sämtliche'. Return-format details are handled 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?

The description is two sentences with no filler. It front-loads the core purpose and then adds the key scoping detail about both Schlüsselnummernfelder; every sentence 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?

Given that this is a read-only, idempotent lookup with a simple 2-parameter schema and an output schema, the description is largely complete. It provides the necessary domain behavior (reverse lookup of an OPS code and inclusion of both key fields). It lacks an explicit alternative-routing statement, but that is not essential for correct invocation.

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 input schema has 100% description coverage for both parameters, so the schema already documents code normalization and the optional year. The description clarifies the high-level lookup concept but adds no new parameter-level semantics beyond what the schema provides.

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 uses a specific verb ('Liefert'), a clear resource ('Einträge des Alphabetischen Verzeichnisses'), and a precise lookup criterion ('auf einen bestimmten OPS-Kode verweisen'). It also explains what is returned — all labels under which the code can be found — which differentiates it from an open text search like opsalpha_search.

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 intended use case is implied: use this when you already have a known OPS code and need all alphabetical index entries referencing it. However, the description does not explicitly state when to use this tool instead of alternatives such as opsalpha_search or ops_get, nor does it mention exclusions.

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 idempotentHint=true, so the description's safety burden is low. It adds value by specifying that each hit includes the associated key numbers and the official title from the systematic directory, giving agents a clear expectation of the response content. This goes beyond the annotations and is useful.

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 three sentences long, front-loaded with the core purpose, and every sentence contributes to understanding the tool's function and output. It is concise, well-structured, and avoids redundancy.

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 is a straightforward search operation with an output schema present. The description explains what the results contain (key numbers and titles), which is the key missing context. It does not explicitly mention pagination behavior, but that is covered by the offset/limit parameters in the schema. Overall, it is sufficiently complete for an agent to use the tool correctly.

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. The description does not add any parameter-specific details beyond what the schema already provides (e.g., query can be a text or a code, limit/offset defaults). It reinforces the purpose of the query but adds no new semantics, so it meets the baseline without exceeding 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 clearly states the tool's function: searching the alphabetical directory of OPS, mapping clinical/colloquial procedure names to key numbers. It also distinguishes it from siblings by noting it is the typical entry point when only the procedure text is known, and each hit includes the official title. This is specific and unambiguous.

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 a clear usage context: 'the usual entry point when only the procedure text is known,' implying the tool is for text-based lookups rather than code-based ones. It does not explicitly name alternative tools like ops_search or opsalpha_get, but the scenario is well-stated and leaves little room for misinterpretation.

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 readOnly/idempotent/closed-world, so safety is covered. The description adds what an agent otherwise wouldn't know: the response is split into 'focus', 'parents' (superordinate codes) and 'items' (directly subordinate codes), and that a codeless call returns the catalog's top level. It doesn't discuss volume of results or rate 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?

Three dense sentences, front-loaded with the main capability, then response structure, then the edge case. No filler. Slightly list-heavy but every clause maps to a real output section.

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?

An output schema exists, so return values needn't be fully spelled out, yet the description usefully names the three response sections. Combined with the null-code behavior and the schema's year handling, an agent has enough to call this correctly. It lacks sibling routing, the only real gap.

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%, so the schema already explains normalization forms and the year fallback logic in detail. The description's default-path sentence ('ohne Kode ... oberste Ebene') duplicates the schema's own note, adding no syntax or format detail beyond it. Baseline 3 is correct.

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?

States a specific verb and resource ('Liefert ... alle Angaben zu einem OPS-Kode') and itemizes the returned facets (Kodier-Kennzeichen, Alters-/Geschlechtsbezug, AOP, Alphabetisches Verzeichnis, DKR/SEG-4) plus the hierarchical parts (parents/items). An agent can tell exactly what it retrieves. It does not explicitly contrast with the sibling ops_search, 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 null-code case is covered ('Ohne Kode aufgerufen liefert die Funktion die oberste Ebene des Katalogs'), which is genuine conditional guidance. However, there is no statement about when to prefer this over ops_search or opsalpha_get, and no exclusions. Usage is implied rather than prescribed.

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 confirm read-only and idempotent behavior, but the description adds substantial non-obvious context: it searches the alphabetical index with roughly 48,000 additional formulations, returns only terminal codable codes, sorts items flat by relevance, and includes coding markers, §115b information, OPS structure checks, DKR/SEG-4 references, and meanings of groupCode, matchedTerm and interpretation.

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 front-loads the first-tool positioning and key scope, then gives useful behavioral detail. It is somewhat long and explains return fields even though an output schema exists, so parts are redundant rather than essential.

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 rich input schema, annotations and output schema, the description covers what is searched, the terminal-code restriction, the structure of returned items, and the next-step routing to ops_get. No critical information needed to select or call the tool correctly is missing.

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. The description adds useful query semantics beyond the schema by emphasizing abbreviations and misspellings such as 'appendektomi' and by reinforcing flexible code/text input, though year and limit remain documented only in the 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?

States a specific verb and resource ('Durchsucht den OPS') and positions itself as the first tool for any procedure question. It explicitly points to ops_get for single-code details and clarifies that only terminal codable codes are returned, distinguishing headings from answer codes.

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?

Explicitly says this is the first tool for any procedure question, enumerates query types including codes, clinical terms, abbreviations and misspellings, and tells the agent to call ops_get afterward for all details on a single code.

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 read-only, idempotent, and closed-world behavior. The description adds meaningful context beyond that: the response grouping into 'focus', 'parents', and 'items', the browse behavior when no code is supplied, and an important caveat that Orphanet's ICD-10 links are WHO ICD-10 rather than Germany's Alpha-ID-SE mapping.

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 retrieval behavior and then covers browsing and the ICD-10 caveat. It is somewhat long and includes a bilingual English restatement that duplicates the German summary, but the content is largely purposeful.

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 is simple, both parameters are fully documented in the schema, annotations cover safety and idempotency, and an output schema exists. The description still supplies useful behavioral and caveat context, making the definition complete for correct invocation.

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%, so both parameters are fully documented in the input schema. The description reinforces the meaning of an empty code by describing catalog browsing, but it never mentions the 'year' parameter or its fallback-to-latest-edition behavior, so it adds little beyond the 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 description states a specific verb and resource: it retrieves everything the nomenclature has for one ORPHA code, including names, synonyms, status, portal links, and ICD/OMIM references. It also explains the no-code behavior as browsing the catalog's top level, which distinguishes it from the sibling orpha_search 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?

It gives a clear usage condition: with a code it returns detailed entry data, and without a code it returns the subject areas for browsing the catalog. It does not explicitly route users to orpha_search when they need to find a code first, so it stops short of full alternative 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 declare readOnly/idempotent/closed-world, so the safety profile is covered; the description adds genuinely useful domain semantics beyond that — the hit facets and the crucial rule that only 'Active' marks a current entry. It stops short of anything about result volume or failure modes, but nothing is contradicted.

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?

Front-loaded with purpose, then output facets, then routing advice — the ordering is deliberate and each sentence carries information. The closing English sentence duplicates the opening for a bilingual audience, which is slightly redundant but defensible.

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?

Three fully documented parameters plus an output schema mean the description need not explain return shapes; what an agent still needs — what to search, what a hit means, and where to go for German coding — is all present.

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% with per-parameter descriptions (including the year and limit defaults), so the schema carries the burden. The description only restates that query accepts a name, synonym or ORPHA code, adding no format or behavior detail beyond what the schema already says.

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?

States a specific verb+resource ('Durchsucht die Orphanet-Nomenklatur der Seltenen Erkrankungen') and enumerates the searchable keys (Bezeichnung, Synonym, Orpha-Kennnummer). It also names the returned entry facets (Art des Eintrags, Einordnung, Status), which lets an agent separate it from icd10alpha_search without opening a schema.

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?

Gives an explicit use case (a disease name not covered by the ICD-10-GM alphabetical index) and an explicit next step ('Für die Kodierung in Deutschland anschließend icd10alpha_search aufrufen'). The when-to-use and the alternative/downstream sibling are both named rather than inferred.

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, idempotentHint=true and openWorldHint=false, so safety and repeatability are covered. The description adds the useful behavioral fact that a code-less call degrades to a catalog-root listing, but says nothing about failure behavior for unknown codes or about the year fallback (that lives only in the 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?

Two tight sentences with no filler, front-loaded with what the response contains. It is efficient, though the ordering (output shape before purpose) means the agent reads the return contract before learning what the tool actually looks 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?

With an output schema present, the description needn't enumerate return values, yet it still names the three key fields, and annotations cover the safety profile; only the get-vs-pepp_search routing decision is left unstated. That single gap keeps it below full marks for a tool with 41 siblings.

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 the schema already documents both `code` (example 'PA01A', leave empty for top level) and the nuanced `year` fallback logic. The description's no-code behavior merely restates what the `code` parameter description says, adding no syntax or format detail beyond the schema; 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 makes clear this is a lookup that returns a PEPP code plus its hierarchical neighbors ('focus', 'parents', 'items'), and that calling it without a code returns the catalog's top level. The verb 'liefert' (returns) frames the purpose via its output rather than an explicit 'retrieve a PEPP code', so it is slightly indirect, but the resource and scope are unambiguous.

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 one concrete usage rule — call without a code to get the catalog's top level — which implicitly contrasts exact-lookup with browsing. However, it never names pepp_search as the alternative for free-text/keyword lookup, so the agent must infer the get-vs-search split from naming convention 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, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds that hits land in 'items', but says nothing about matching semantics (substring vs exact), case sensitivity, or behavior when the catalog year is omitted beyond what the schema states.

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?

Two short sentences, front-loaded with what the tool does; the acronym expansion earns its place. No filler, though the 'items' note is marginal given an output schema exists.

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 read-only search over a well-documented 3-parameter schema with an output schema present, this is nearly complete. The only gap is search matching behavior, which is minor given the rich structured fields.

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 year, limit and query are fully documented in the schema. The description's "nach Kode oder Bezeichnung" merely restates the query parameter and adds no format or matching detail beyond 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?

States a specific verb ("Durchsucht") and resource (PEPP-Katalog), and even expands the acronym for clarity. It does not explicitly contrast with the sibling pepp_get, relying on the search/get naming convention instead.

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?

Usage is only implied: it searches by code or label, which suggests a lookup-style tool, but there is no statement about when to prefer pepp_get over pepp_search or any exclusions. No prerequisites or edge cases are mentioned.

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 readOnly/idempotent/closed-world, and the description adds real behavior: results are ordered most-binding-first, carry date, validity period and source link, and parent-code rules are inherited (8-98f → 8-98f.20). This goes well beyond 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?

Front-loads what is returned, then explains inheritance and the applicability switch. Dense but every clause (source enumeration, sort order, inheritance example, applicability logic) carries information; parenthetical examples aid rather than pad.

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, full annotations, and 100% schema coverage, the description supplies the remaining semantics an agent needs — inheritance, ordering, and the conditional applicability model — so nothing required to call it correctly is missing.

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%, so baseline is 3, but the description adds cross-parameter semantics the schema doesn't: inheritance of parent-code rules and the conditional interaction of 'aufnahmedatum'/'pruefungAm'/'year' on applicability. It clarifies meaning beyond the per-param descriptions.

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?

States a specific verb (Liefert) and resource (alle Regeln außerhalb des Katalogs zu ICD/OPS/DRG-Kodes) and enumerates the three source types (DKR, Schlichtungsausschuss, SEG-4). It is clearly distinguished from the catalog-rule sibling rules_get, which the description implicitly contrasts by saying 'außerhalb des Katalogs'.

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?

Gives explicit conditional usage: 'year' only without 'aufnahmedatum', 'pruefungAm' only with 'aufnahmedatum', and explains that 'aufnahmedatum' toggles per-rule 'anwendbarkeit'. It doesn't explicitly name sibling alternatives like rules_get, but the parameter-combination guidance is strong.

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, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful claim that the record is returned "vollständig" with all affected codes and their roles, but says nothing about error behavior for an unknown id or about output size/pagination.

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 with no filler; the enumeration of returned fields is compact and informative. Slightly over-dense for one sentence but nothing 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?

With an output schema present, the description needn't document return values, and one fully documented required parameter plus read-only annotations means little else is required. Purpose and payload scope are covered adequately for a simple getter.

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?

Only one parameter, and schema description coverage is 100% — the schema already explains that the id comes from 'rules_for_code' and gives concrete examples. The description adds no additional meaning about the identifier format or semantics, so 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?

States a specific verb ("Liefert") and resource ("Regelereignis") and enumerates the payload (betroffene Kodes mit Rolle, Geltungszeitraum, Prüfstatus, Quelle), so the agent knows exactly what it gets back. It does not, however, distinguish itself from the sibling rules_for_code, which an agent could easily confuse with it.

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 contains no when-to-use guidance, no prerequisites and no mention of alternatives such as rules_for_code. The only routing hint lives in the schema property description ("Kennung aus 'rules_for_code'"), not in the tool description itself.

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 annotations (readOnly, idempotent), the description discloses what is returned – full text in 'focus', the publication and modification dates, and the embedded ICD/OPS/DRG codes – plus the no-parameter fallback to the outline level. That is real behavioral context the annotations cannot carry.

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?

Two compact sentences with the main return contract front-loaded and the fallback behavior last. No filler, though neither sentence is spent on routing or prerequisites.

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 a full output schema and fully documented parameters, the description only needs to frame what a call yields, and it does: Volltext, dates, contained codes, and the outline-mode behavior. Sufficient for correct invocation.

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 the schema already explains both 'code' and, in detail, the 'year' fallback to the newest Fassung. The description only restates the no-number case, adding no syntax or format detail beyond the schema; 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?

States a specific verb and resource (Volltext einer SEG-4-Kodierempfehlung abrufen) and enumerates the payload: Veröffentlichungs-/Änderungsdatum sowie ICD-, OPS- und DRG-Kodes. It does not name the sibling seg4kde_search, so the get-vs-search split has to be inferred.

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 only usage signal is 'Ohne Nummer aufgerufen liefert die Funktion die oberste Gliederungsebene', which implies a browse mode. There is no explicit statement of when to use this instead of seg4kde_search or of any exclusion.

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, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds modest context about the result set ('items' containing full text and ICD/OPS/DRG codes), but says nothing about matching semantics, ordering, or pagination. A 3 is appropriate because annotations carry the main behavioral burden and the description adds only limited extra information.

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 sentences with the purpose front-loaded, followed by a compact note on the result contents. There is no wasteful or redundant phrasing, and the structure is immediately usable.

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 low complexity, full schema descriptions, existing output schema, and annotations, the description is nearly complete for correct invocation. The only notable gap is the absence of a pointer to seg4kde_get for direct retrieval by number, but that is a minor 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 100%, so all three parameters are already documented. The description repeats that the query can be a number or text keyword, which matches the schema wording but adds no new parameter semantics, so the baseline of 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 specific verb and resource: searching the SEG-4 coding recommendations of the MDK-Gemeinschaft by number or text. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling seg4kde_get beyond the search vs. retrieval verb.

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?

Usage is implied by 'nach Nummer oder Text', indicating the tool is appropriate for keyword or number lookups. However, there is no explicit guidance on when to use this instead of seg4kde_get, nor any stated exclusions or prerequisites.

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 readOnly, idempotent and closed-world, so the safety profile is covered. The description still adds behavioral value by spelling out the depth of the payload, including the subtle 'grau hinterlegte Kombinationspartner' on OPS codes and footnote contents (age limits, minimum stay, exclusions).

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?

Two sentences, front-loaded with the core behavior and followed by the no-argument case. The middle enumeration is dense but each item maps to real output content, so little 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?

With annotations covering safety and an output schema present, the description does not need to explain return structure, yet it helpful does. What remains thin is the get-vs-search relationship, which matters given the ze_search sibling.

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%, so both parameters are already documented, including the year fallback behavior. The description's remark about calling without a code returning the catalog top level merely restates the schema's 'Leer lassen' note, adding no format or semantics beyond it — 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?

States a specific verb and resource ('Liefert ... alle Angaben zu einem Zusatzentgelt') and enumerates exactly what comes back: amount, triggering OPS codes, ICD codes, fallpauschalen, footnotes. It does not name the sibling ze_search to draw the get-vs-search boundary, 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 note that calling without a code returns the top level of the catalog is an implied usage rule, but there is no explicit guidance on when to use this instead of ze_search or when a specific year should be supplied (that lives only in the schema). Usage is inferable rather than stated.

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 cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), and the description goes beyond them by explaining what the results contain: 'items' with Betrag, Herkunft (bewertet vs. krankenhausindividuell), and the number of triggering OPS/ICD codes. It does not mention ranking or whether partial matches are returned, keeping it short of a 5.

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?

Two sentences, zero waste, with the core search behavior front-loaded and the result-shape detail second. Nothing is repeated from the title or schema.

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?

An output schema exists, so return values need not be fully spelled out, and the parameter schema is complete. The description still adds useful orientation about result composition; only minor gaps remain (no hint that ze_get retrieves full details for a hit).

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 query, year (default latest) and limit (1-100, default 25) are fully documented in the schema itself. The description restates the query semantics (ZE code like 'ZE01' or a service description) but adds no new parameter guidance, so the baseline of 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?

States a specific verb ("Durchsucht") and resource ("Zusatzentgelte-Katalog") plus the two searchable fields, Kode and Leistungsbeschreibung. It does not explicitly distinguish itself from the sibling ze_get, so an agent must infer the search-vs-fetch split from the names alone.

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?

Usage is only implied: the description tells you it searches by code or description, which suggests using it for lookup-by-term, but it never says when to prefer ze_get instead or what to do after getting hits. No exclusions or prerequisites are given.

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