DRGSystem — German medical coding catalogs

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

Annotations already mark the tool as readOnly, idempotent, and not open-world, so the safety profile is clear. The description adds valuable behavioral detail beyond annotations by disclosing the response sections ('focus', 'parents', 'items') and the special behavior when no code is supplied. It does not describe invalid-code handling, but this is minor for a read-only lookup.

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 well-structured sentences with no filler. The first sentence front-loads the key output behavior, and the second efficiently explains the optional-code case. Every sentence adds necessary 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?

For a read-only tool with two optional parameters, complete schema documentation, an explicit output schema, and strong readOnly/idempotent annotations, the description covers what an agent needs to invoke it correctly. It explains optional invocation and the structure of results without over-explaining.

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%, with both 'code' and 'year' already documented in the input schema. The description reinforces that omitting 'code' returns main groups, but it does not add meaningful information about 'year' or parameter formatting beyond what the schema 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 names the concrete verb 'Liefert' and the resource 'ATC-Kode', and clearly specifies what is returned in 'focus', 'parents', and 'items'. It also distinguishes itself from the sibling 'atc_search' by describing hierarchical retrieval with parent/child structure rather than search, and by explaining the no-code root-group 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?

The description gives clear usage context: pass a code to get focus/parents/items, or omit the code to get anatomical main groups. It does not explicitly mention when to prefer 'atc_search' instead, but for this retrieval-style tool the conditional behavior is strong enough 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 readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context beyond those annotations by specifying that results are returned in 'items' and include DDD and associated ICD codes. It does not go into detail about pagination or edge cases, but the core search behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence that leads with the main action and immediately follows with the result format. There is no filler, repetition, or extraneous detail; every clause contributes useful 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?

For a straightforward search tool, the description is complete enough: it names the resource, search inputs, and the key fields in the result. The input schema fully documents parameters, annotations cover safety and idempotency, and an output schema exists, so the agent has sufficient context to select and invoke 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 description does not need to re-explain the parameters. It does reinforce that 'query' can be an ATC code or substance name, but this adds little beyond the schema. The description adds no new semantic detail for 'year' or 'limit', so 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 ('Durchsucht'), a clear resource ('amtliche ATC-Klassifikation'), and the search criteria ('nach Kode oder Wirkstoff'). It also indicates the result shape ('Treffer stehen in items'), which separates it from a simple exact-code retrieval tool like atc_get.

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 general intent clear: use this tool to search the ATC classification by code or substance. However, it does not explicitly mention when to prefer atc_get over atc_search, nor does it state any exclusions. The usage guidance is implied rather than explicit.

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?

Given the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral detail: it discloses the exact response roles and the default top-level behavior when 'code' is omitted. This goes beyond the annotations and helps an agent predict what the tool will do.

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, no filler, with the primary behavior front-loaded and the no-argument fallback stated second. 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?

For a read-only, idempotent retrieval tool with only two optional parameters and an output schema present, the description is largely sufficient. It covers return fields and the no-code case; the only minor gap is not steering agents toward dkr_search for lookup-style 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 the input schema already documents 'code' and 'year' thoroughly. The description reiterates the empty-code behavior but adds no further parameter detail, such as year formatting or validation restrictions.

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 that the tool retrieves a Volltext of a Kodierrichtlinie and identifies the response sections 'focus', 'parents', and 'items'. It does not explicitly contrast itself with sibling tools like dkr_search, but its get-vs-search role and the no-code fallback behavior are clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives practical usage context: calling with a DKR number returns the rule content, while omitting the number returns the top-level structure. It does not explicitly tell the agent when to use dkr_search instead, but the invocation conditions are clear enough for a get tool.

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 provide readOnlyHint, idempotentHint, and non-destructive behavior. The description adds behavioral value by disclosing that results appear in 'items' and already contain the full text of the guideline, which saves the agent from making an unnecessary follow-up call.

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 concise sentences: the first explains what the tool does, and the second gives the key output behavior. Information is front-loaded and there is no filler or repetition.

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, annotations, and fully documented schema together give an agent enough to select and invoke the tool correctly. It is only missing an explicit recommendation for when to use dkr_get for exact retrieval and some edge-case behavior such as empty result sets.

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 already documented with defaults, bounds, and examples. The description only reinforces that search can be by number or text and does not add substantial parameter-level meaning 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 names a specific action ('Durchsucht'), a clear resource ('Deutschen Kodierrichtlinien (DKR)'), and the search scope ('nach Nummer oder Text'). It is not a tautology, but it does not explicitly contrast itself with the sibling dkr_get, so the get/search differentiation remains 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?

The description clearly implies that this is the DKR search tool, which is useful context. However, it gives no explicit guidance about when to prefer this over dkr_get or other related search tools, and it does not state any when-not-to-use or alternatives.

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 no safety ambiguity exists. The description adds meaningful behavioral context: that a null/empty code triggers a different behavior (returning the top-level MDC), and that the response contains not just a single value but a composition of all catalog details, footnotes, and supplementary fees. It is transparent about the conditional behavior without contradicting 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?

The description is a single, dense sentence that enumerates the full return payload without fluff, and ends with the crucial empty-code behavior. Every clause adds information; no content 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?

The output schema is present, so the exact return shape is already structured. Annotations cover read-only and idempotent behavior. The description adds the remaining contextual glue: how the input parameter changes the scope and what content areas are included. For a read-only GET-style lookup with two optional parameters and an output schema, this is 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 both parameters (code, year) are clearly documented in the schema with examples and defaults. The description reinforces that 'code' is the primary semantic driver ('Ohne Kode aufgerufen...'), which adds a little context beyond the schema, but does not significantly change the baseline of 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?

The description begins with a specific verb ('Liefert') and names the exact resource (Fallpauschalenkatalog) and the primary access key (DRG), enumerating the returned data fields. It also contrasts itself with sibling search tools by stating that a code is required to get details, otherwise it returns the top-level MDC.

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 clearly explains the two invocation modes: with a DRG code for detailed catalog data, and without a code for the MDC top level. It does not explicitly name alternatives like drg_search or other lookup tools, but the 'Ohne Kode aufgerufen...' sentence provides solid usage context for when to call this tool.

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 useful behavioral detail: results appear in 'items' with specific fields such as Partition, leading assessment relation, and length-of-stay values, and it notes that full attachment values are not included in this tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with no filler. The first sentence states the action and scope; the second describes the response shape and points to the alternative tool. Information is front-loaded and 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?

For a read-only search tool with full schema coverage and an output schema, this description is complete. It explains what is searched, what the response contains, and when to switch to drg_get. No critical information is missing 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 description coverage is 100%, so all three parameters (year, limit, query) are already documented with defaults and examples. The description reinforces that query accepts a code or label, but it does not add meaningful semantic information 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 uses a specific verb ('Durchsucht') with a concrete resource ('Fallpauschalenkatalog (G-DRG)') and states the two search dimensions: code or label. This clearly separates it from catalog-specific siblings like dkr_search or ops_search and from drg_get, which is explicitly named for complete values.

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 states when to use the tool (search by DRG code or designation) and explicitly routes users needing the complete values of all attachments to drg_get. This gives an agent a clear decision rule among sibling tools.

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 read-only and idempotent behavior, lowering the bar. The description adds meaningful behavioral context beyond annotations: it enumerates that primary, star, additional, and second-primary key numbers are all considered, and explains that the result is every string in the alphabetical index referencing the code. It does not cover edge cases like missing codes, but the output schema handles 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?

The description is reasonably compact: a German sentence stating the core behavior, a second sentence adding key-type coverage, and an English summary that repeats the main idea for bilingual accessibility. Every part carries substantive information; the bilingual duplication is a minor inefficiency rather than fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only reverse lookup with two parameters, full schema coverage, and an output schema present, the description is nearly complete. It explains what the tool returns, which key types are included, and the practical use case. It doesn't mention invalid-code behavior or year availability, but these are minor gaps given the annotations and schema already cover safety and parameter constraints.

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?

Input schema description coverage is 100%, and both parameters ('code' and 'year') are already explained in the schema with examples and defaults. The tool description adds no further parameter-level 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 uses a specific verb ('Liefert') and resource ('Einträge des Alphabetischen Verzeichnisses') tied to a clear lookup criterion (a given ICD-10-GM code). It precisely distinguishes this reverse-lookup tool from forward lookups or text searches by stating it returns every wording that points to the code, covering primary, star, additional, and second-primary keys.

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 clearly frames the intended use: given an ICD-10-GM code, discover all index wordings that lead to it, especially useful for seeing covered clinical and everyday terms. It implies the alternative is a text-based search over the alphabetical index (e.g., icd10alpha_search) without naming it explicitly, and it does not state when-not-to-use exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context about the result content: 'Jeder Treffer nennt Primär-, Stern- und Zusatzschlüsselnummer bereits mit ihrem amtlichen Titel...'. This goes beyond the structured metadata and sets expectations for what each hit will contain.

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 moderately sized and front-loaded with the core purpose, followed by usage conditions and alternatives. The German/English duplication repeats some content, but each sentence carries useful information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with an output schema, 100% parameter coverage, and readOnly/idempotent annotations, the description is largely complete: it gives purpose, when to use it, alternatives, and even describes the code types returned. The only minor gap is a slight tension between recommending icd10_search for known codes while the query parameter allows a code; this does not seriously impair completeness.

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, limit, and offset. The description adds the natural-language and partial-term use case with examples like 'Herz', 'Diabetes', 'Schmerz', but this supplements rather than replaces the schema. A baseline 3 is appropriate because the description does not need to compensate for missing parameter docs.

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 Alphabetische Verzeichnis der ICD-10-GM' and explains it maps clinical/colloquial diagnosis terms to ICD-10-GM codes. It also explicitly distinguishes itself from icd10_search and icd10_get, so an agent can tell them apart without opening schemas.

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 when-to-use guidance: 'Best first tool for natural-language diagnosis search: use it when the user asks to find diagnoses by text, symptom, disease name, colloquial German wording or a partial term...'. It also names alternatives and the conditions for choosing them: use icd10_search when an ICD code is already known and icd10_get for the full entry of one 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?

The annotations already mark the tool as read-only and idempotent, and the description adds rich behavioral detail beyond that: it discloses the response structure ('focus', 'parents', 'items'), enumerates the content categories, and specifies that a call with no code returns the top level for hierarchical browsing. This goes well beyond the structured hint and matches 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?

The description is dense but not bloated; the German paragraph enumerates the major result sections in one efficient clause, and the English sentence summarizes the same intent. Slight repetition across languages is acceptable for a bilingual tool, and the key usage guidance is front-loaded near the end and clear.

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 the output schema exists, the parameter schema covers both optional parameters, and annotations declare the tool read-only and idempotent, the description completes the picture by explaining the browse-from-root behavior and the distinction from search tools. Nothing essential is missing for an agent to select and invoke this 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?

The schema already provides 100% coverage for 'code' and 'year', including normalization examples and defaults. The description adds meaningful semantics by explaining that omitting 'code' produces the top catalog level, which is not just a null default but a distinct browsing behavior. This supplements the schema without repeating 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 names a specific verb and resource: it delivers all details for an ICD-10-GM code, including coding flags, inclusions/exclusions, notes, index entries, and cross-references. It also distinguishes itself from search tools by stating it inspects a hit or browses the catalog from the top, which separates it from icd10_search and icd10alpha_get.

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 explicitly says when to call this tool: 'Call it after a search to inspect a hit' and 'call it without a code to browse the catalog from the top.' This gives clear, actionable guidance for choosing it over the sibling search tools, and explains the null-code browse entry point without 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 carry the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=false), so the description's extra disclosure counts: results arrive in 'items' as complete catalog rows with the full coding-flag set (Alters-/Geschlechtsbezug, CCL, Chroniker, IfSG-Meldepflicht, Morbi-RSA, DKR-/SEG-4-Verweise). It also states what the tool does NOT return (per-code Inklusiva/Eklusiva/Kodierhinweise) and routes to icd10_get. Not a 5 because search-matching behavior (partial-kode matches, ordering, case handling) is not disclosed — a miner gap given the output schema documents return shape.

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?

Core capability is front-loaded in the first sentence and usage routing comes last, which is well ordered. However, the bilingual German/English format repeats the search capability and result-content points in both languages, so a substantial share of the text is redundant; each language half is tight on its own, but combined, not 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?

For a medium-complexity search tool in a large domain family (25 siblings spanning ICD-10, alpha catalogs, OP S, DRG, ATC, and more), the description resolves the critical routing decisions: systematic-vs-alphabetal search, code-vs-free-text input, and single-code follow-up — and states exactly what the returned rows contain. With annotations covering safety and an output schema covering return values, nothing needed for correct invocation 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% — year, limit, and query each carry their own descriptions with concrete examples ('E11', 'E11.0', 'Diabetes mellitus Typ 2'), so the schema does the heavy lifting. The description re-states that query may be a code or diagnosis text but adds no parameter-level syntax or format detail beyond the schema. Baseline 3 applies when schema coverage is high.

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 den ICD-10-GM (amtlicher Diagnoseschlüssel) nach Kode oder Diagnosetext' — searches the ICD-10-GM catalog by code or diagnosis text. It also distinguishes itself from the closest siblings by name: icd10alpha_search for natural-language wording and icd10_get for single-code details. An agent can tell this tool apart without opening any 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 explicit routing: 'Use this when an ICD code is already known or systematic rows are wanted; when the user only has natural-language wording... call icd10alpha_search first', and names the follow-up protocol for per-code details ('Für Inklusiva, Eklusiva und Kodierhinweise... anschließend icd10_get aufrufen'). Both when-to-use and when-not-to-use are spelled out with named alternatives — exactly what is needed in a 25-tool sibling family.

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 description adds meaningful behavior beyond the annotations: the response is delivered in 'focus', and the function's behavior changes depending on whether no code, a regional key, or an IK is provided. The annotations already cover read-only and idempotent traits, so the additional hierarchical behavior is valuable and non-redundant.

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 focused sentences with no filler. The core purpose is front-loaded, and the second sentence adds the necessary hierarchical behavior without repeating schema details.

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, idempotent, two-parameter tool with an output schema, the description fully covers the invocation modes and the expected resource contents. There are no critical gaps for an agent to select and call 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?

The schema already documents both parameters fully, so the baseline is 3. The description enriches the code parameter semantics by explaining that an IK returns the complete hospital record while a regional key returns the underlying directory level, and that an empty code returns the top-level Bundesländer.

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') and names the exact resource: complete hospital data including Name, Träger, Anschrift, Bundesland, Kreis, and contact details. It also distinguishes the tool's behavior from the sibling search tool by describing the hierarchical catalog levels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear invocation conditions: no code returns Bundesländer, a Bundesland or Kreis key returns the next lower level, and an IK returns hospital details. It does not explicitly name kh_search as the alternative for fuzzy or filtered lookups, so it stops short of explicit 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 readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile and closed-world behavior are covered. The description adds helpful output context (results in 'items') and points to kh_get for details, but does not describe pagination, sorting, or whether partial matches are supported. With these annotations, a middle score is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with what the tool does and ending with a routing pointer to kh_get. No filler, 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?

For a read-only search tool with a rich 100%-covered schema and an output schema, the description is largely complete. It even tells the agent where results land ('items') and where to get address/contact details. It could improve by noting that the search returns only summary data, but the pointer to kh_get already communicates this. Minor gap, not a major one.

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 each parameter is already documented in the schema. The description adds some semantic value by restating the query field's options (IK, name, or place), but it does not go beyond the schema for year or limit. This matches the baseline of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Durchsucht') and the explicit resource ('Krankenhausverzeichnis'), and enumerates the three searchable fields (IK, name, or place). It also differentiates itself from kh_get, which fetches details for a single hospital, so the agent can clearly tell search from retrieval.

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 notes that search results are returned in 'items' and explicitly routes detail needs to kh_get: 'Anschrift und Kontaktdaten liefert kh_get zum einzelnen Haus.' This tells the agent when to use this tool and when to switch to a sibling, although it does not describe exclusions like OR/AND semantics or exact-match requirements.

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 and idempotent behavior. The description adds useful non-obvious behavior: the result is delivered in 'focus', quality criteria are grouped by Anforderungsbereich, references to other Leistungsgruppen are resolved in both directions, and calling without a code returns the top-level hierarchy. This goes beyond what annotations alone provide.

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 dense sentences with no filler. It front-loads the primary deliverable and behavior, then adds the conditional no-code case at the end. Every sentence contributes meaningful 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?

For a read-only lookup tool with a rich output schema, fully documented optional parameters, and safety annotations, the description covers the non-obvious behavioral aspects: grouping, bidirectional reference resolution, and the no-code fallback. Nothing critical is missing for an agent to call 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 schema already documents both parameters with examples and default behavior. The description only echoes the no-code case and adds no additional parameter-level semantics beyond what the input 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 opens with a specific verb ('Liefert') and names the exact resource (Leistungsgruppe nach § 135e SGB V) with its content (Qualitätskriterien, Teilanforderungen, Anforderungsbereiche). It also distinguishes this from other catalog siblings by focusing on the LG-specific structure and the no-code top-level 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 gives clear guidance for two call modes: with a code and without a code. However, it never explicitly names lg_search as the alternative for keyword-based lookup or states when an agent should prefer search over get. The guidance is implied by the naming and schema rather than stated in the description.

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?

The annotations already mark the tool as read-only and idempotent, and the description adds that matching is performed over the wording of quality criteria and that hits are returned under 'items'. No destructive or side-effect behavior exists to disclose, and the search behavior is more explicit than the bare search verb.

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 compact German sentences state the action, the searchable scopes, an illustrative use case, and the result location. The most important verb and resource are front-loaded in the first sentence, with no redundant restatement of 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?

For a search tool with only three parameters, a full input schema, and an output schema, the description covers what is searched, how to phrase a query, what additional question it can answer, and where results appear. Nothing an agent needs to invoke 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 input schema already documents query, year, and limit. The description reinforces the query semantics with new examples ('Linksherzkathetermessplatz', 'Rufbereitschaft jederzeit') and the reverse-lookup capability, but it does not materially change or add parameter requirements.

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 the specific verb 'Durchsucht' and identifies the resource as 'Leistungsgruppen nach § 135e SGB V', further scoping the search fields to 'Nummer, Bezeichnung und Wortlaut ihrer Qualitätskriterien'. It also adds the non-obvious reverse-lookup use case, so an agent can distinguish this search tool from plain getter siblings such as lg_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear contexts: searching by number/name/wording and answering the reverse question of which Leistungsgruppen require a certain criterion, e.g. 'Linksherzkathetermessplatz'. It does not explicitly tell the agent to use lg_get when an exact Leistungsgruppe is already known, so it stops short of a full when-to-use/when-not-to-use statement.

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, lowering the bar. The description adds useful behavioral context: it returns all matching entries rather than one, and it states that both key-number fields of the entry are considered during matching. No behavioral claim contradicts 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 short sentences with no filler; the main purpose is front-loaded and the second sentence adds a precise matching detail. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only code lookup with a full input schema and an output schema, the description plus annotations cover what an agent needs to invoke it correctly. It clarifies the lookup semantics and does not need to restate return-value details because an output schema exists.

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 schema already covers both parameters at 100%, so the baseline is 3. The description adds extra meaning by specifying that the supplied code is matched against both key-number fields of the entry, which is not in the schema description for 'code'.

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') and a specific resource ('Einträge des Alphabetischen Verzeichnisses') tied to a lookup key ('bestimmten OPS-Kode'). It also clarifies the return scope ('sämtliche Bezeichnungen...'), which distinguishes this by-code lookup from the sibling *_search tools and from lookups in other code systems.

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 is reasonably clear: call this when you have an OPS code and need all alphabetical index entries that reference it. However, the description does not explicitly state when not to use it or contrast it with opsalpha_search, so the guidance remains implied rather than explicit.

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 the tool read-only and idempotent, so the safe-behavior burden is low. The description adds value by revealing that each hit includes the corresponding key numbers with their official title from the systematic directory, informing the agent what to expect in 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 sentences, all essential: the action, the purpose/context, and the output composition. It is front-loaded and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a complete input schema, read-only/idempotent annotations, and an output schema available, the description contributes the missing conceptual context: what the alphabetical directory is, when it is the right entry point, and what the results look like. No critical gap remains for a tool of this complexity.

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 four parameters already have full descriptions, defaults, and examples. The description does not add parameter-specific detail, but no compensation is needed given the complete 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 identifies a specific action ('Durchsucht') and resource (the alphabetical directory of OPS), and clearly explains that it maps clinical/colloquial procedure terms to key numbers. It also positions itself as the standard entry point when only the procedure text is known, distinguishing it from systematic-directory and code-lookup siblings without naming them 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 description states when to use it: when only the procedure text is known and the user needs the associated key numbers. This provides clear situational context, though it does not explicitly name sibling alternatives or exclusions, so it stops short of a full 5.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds valuable behavioral context by detailing the return structure ('focus', 'parents', 'items'), the no-code top-level fallback, and the specific content included in the response. No contradiction with 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?

The description is dense but well-structured, front-loading the main result ('focus') before addressing hierarchy and the no-code edge case. Every sentence contributes information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the primary lookup behavior, the hierarchical parent/child output, and the special case of calling without a code. Since an output schema exists, there is no need to restate return-value structures. Nothing critical is missing for this read-only exact-code lookup.

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 already documents both parameters at 100% coverage, including the null behavior for 'code'. The description reinforces the no-code behavior but does not add substantial parameter-level meaning beyond what the schema provides, 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 uses a specific verb ('Liefert') and resource ('OPS-Kode'), then enumerates exactly what is returned: coding flags, age/sex references, AOP details, alphabetical index entries, and DKR/SEG-4 references. This clearly differentiates it from search-oriented siblings by describing an exact-code detail retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear invocation contexts: pass a code to get details, or omit it to receive the top catalog level. It does not explicitly mention alternatives such as ops_search, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral value by disclosing the response structure ('Treffer stehen in items') and the specific data elements included, such as Kodier-Kennzeichen, §115b SGB V information, and DKR/SEG-4 references. This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately explains the search behavior and then adds compact, relevant detail about result contents. There is no filler or repetition of the schema; every clause contributes meaning.

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 search tool with full parameter descriptions, read-only/idempotent annotations, and an output schema, the description is largely complete. It explains what is searched, what query forms are accepted, and what the result items contain. However, given the large sibling list including opsalpha_search, a brief note on when not to use this tool or which sibling covers the alphabetical index would make it fully unambiguous.

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 already has a clear description: query supports code or text, year selects the catalog year, and limit controls the maximum number of hits. The description adds no additional parameter-level meaning beyond the schema, so the baseline of 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 action ('Durchsucht den OPS') and a clearly defined resource (OPS), plus the two accepted query modes: Kode or Prozedurtext. It also describes what the results contain, which makes the tool's purpose distinct from the 'get' siblings in the tool list.

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 is implied: use this tool when you need to search OPS by code or procedure text. However, there is no explicit guidance about when to prefer ops_get, opsalpha_search, or other sibling search tools, so the agent must infer the boundary from the name and description 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?

With readOnlyHint and idempotentHint annotations already covering the safety profile, the description adds meaningful behavioral detail: the response structure ('focus', 'parents', 'items') and the special behavior for null input. This goes beyond the annotations without contradicting them.

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. The primary output structure is front-loaded, and the special no-code case is stated succinctly in the second sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple two-parameter schema, existing output schema, and safe annotations, the description is complete for accurate invocation and interpretation. It covers the main behavior, the hierarchy returned, and the root-level fallback.

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%: both 'code' and 'year' already have clear descriptions with examples and defaults. The description adds no new parameter semantics beyond what the schema provides, so the baseline score of 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 (PEPP-Kode) and details what is returned in 'focus', 'parents', and 'items', making the tool's purpose unmistakable. It is clearly distinct from the sibling pepp_search semantically, but it does not explicitly name or contrast that alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: call with a code for hierarchy information, or without a code for the top catalog level. However, it does not explicitly state when to prefer this tool over pepp_search or any other sibling, leaving routing to the agent inferred rather than guided.

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, so no safety disclosure burden remains. The description adds the result location ('items') and catalog context, but doesn't discuss match behavior, pagination, or errors; with the output schema present this is adequate but not rich.

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 with the action and resource front-loaded; the parenthetical expands the acronym and the second sentence names the result key. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter search tool with full schema descriptions and an output schema, nothing essential is missing. The agent can select, invoke, and interpret the tool correctly from this definition plus its 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 the schema already documents query, year, and limit. The description only reinforces that query accepts codes or labels without providing additional parameter semantics 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 uses a specific verb ('Durchsucht') plus a named resource ('PEPP-Katalog') and specifies the two search axes (code or label). This clearly differentiates it from sibling catalog searches and from pepp_get.

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 conveys this is the search entry point for the PEPP catalog by code or label. It doesn't explicitly name pepp_get as the alternative for exact single-code lookups, so it stops short of full 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 signal read-only and idempotent behavior. The description adds useful behavioral detail beyond that: results are delivered in 'focus', include publication/change dates and ICD/OPS/DRG codes, and null input returns the top-level structure. No contradiction with 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 dense sentences with no filler. The primary output contract is front-loaded and the nullable-code case is handled in the second sentence without repetition.

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, idempotent getter with two optional parameters and an output schema, the description covers the essential call variants and return contents. Nothing critical is missing for an agent to invoke 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%, so both 'code' and 'year' are already documented in the input schema. The description's statement about calling without a number largely restates the schema's 'Leer lassen für die oberste Gliederungsebene' and adds only marginal value.

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 (SEG-4-Kodierempfehlung), and clarifies that it returns the full text plus metadata and codes, optionally at the top level. This is clear, but it does not explicitly differentiate from the sibling seg4kde_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 description implies when the tool is appropriate: call with a recommendation number for full text, or without it for the top-level hierarchy. However, it gives no explicit guidance on when to prefer this tool over seg4kde_search or how to obtain a number if unknown.

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 useful behavioral context by revealing that matches are placed in an 'items' collection and include the full text plus embedded ICD-, OPS-, and DRG-Kodes. It does not contradict 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?

The description is two sentences: one for action and scope, one for result shape. It contains no filler and front-loads the core operation and resource.

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 three well-documented parameters and an output schema, this description is complete. The agent knows what is searched, what a result will contain, and the safety/idempotence profile from the annotations; year and limit are already documented in 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 the schema already documents query, year, and limit semantics. The description's 'nach Nummer oder Text' paraphrases the query field description and adds no substantive parameter information 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 a specific verb ("Durchsucht"), a concrete resource ("Kodierempfehlungen der SEG-4 der MDK-Gemeinschaft"), and the search criteria ("nach Nummer oder Text"). It also specifies that results appear in 'items' and contain full text plus ICD-, OPS-, and DRG-Kodes, so the purpose is clear. It does not explicitly contrast itself with seg4kde_get, so it falls just short of full sibling differentiation.

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 rather than explicitly stated: searching 'nach Nummer oder Text' tells an agent this is the broad search entry point, and the consistent search/get sibling naming pattern reinforces it. However, there is no explicit when-to-use/when-not-to-use guidance and no pointer to seg4kde_get for exact recommendation retrieval.

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, covering the safety profile. The description adds meaningful behavioral context: the response is delivered 'in focus', includes gray-shaded combination partners, associated ICD codes, case rates, and footnotes, and the top-level catalog behavior when no code is given. It enriches the annotation picture without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, dense sentence that front-loads the primary deliverable and then enumerates the included data elements. It is efficient and structured with a colon and comma-separated list, though the lengthy enumeration could arguably be shortened given that 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?

The tool has an output schema and 100% schema description coverage, so return values and parameters are already covered. The description sufficiently covers special behaviors: no-code invocation returns the top level, and the response includes combination partners and footnotes. Minor gap: it does not mention when to route to the search sibling, but that is not essential for invoking this get 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 input schema already explains both 'code' and 'year' with examples, defaults, and null behavior. The description's statement about calling without a code mirrors the schema's 'Leer lassen' guidance and adds no new parameter 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 clearly states a specific verb and resource: it returns ('Liefert') all details for a Zusatzentgelt, enumerating the exact data fields included. It also notes the no-code behavior (returning the catalog's top level). However, it does not explicitly contrast itself with sibling tools like ze_search, so it lacks explicit sibling differentiation.

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 this is the tool to use when you have a specific ZE code and need its full details, and it explains what happens if no code is provided. However, it never explicitly states when to prefer this tool over the sibling search tool ze_search, offering no when-not-to-use 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?

Beyond the readOnly and idempotent annotations, the description discloses the result shape: items with amount, origin category, and counts of triggering OPS and ICD codes. This adds meaningful behavioral context without contradicting 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?

The description is a single focused sentence that states the action, the accepted input types, and the key result fields. It is concise, front-loaded, and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with a full schema and output schema, the description covers the core search behavior and result contents. It lacks explicit guidance on result ordering, empty-result behavior, or differentiation from ze_get, but these are minor given the schema and annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents query, year, and limit. The description adds no substantial parameter meaning beyond confirming that the query can be a ZE code or a service description; 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 clearly states the tool searches the Zusatzentgelte-Katalog by code or service description, and it mentions what the results contain. It does not explicitly contrast itself with ze_get or other sibling get/search tools, but the resource and action 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?

The description implies its use for searching by code or text, but it gives no explicit guidance on when to use this search tool instead of ze_get or another sibling. There are no exclusions or alternative-tool recommendations.

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