DRGSystem — German medical coding catalogs

Ergänzendes Tagesentgelt abrufen

et_get

Read-onlyIdempotent

Liefert in 'focus' ein ergänzendes Tagesentgelt mit Bewertungsrelation je Tag, OPS-Kodes und Fußnoten; in 'items' die Differenzierungen (ETD). Das Entgelt je Tag ist Bewertungsrelation × krankenhausindividueller Basisentgeltwert; abgerechnet wird es zusätzlich zu den bewerteten PEPP der Anlagen 1a und 2a (§ 6 PEPPV). Ohne Kode die oberste Ebene des Katalogs.

Input Schema

Name	Required	Description	Default
`code`	No	ET-Kode (z. B. 'ET01' oder 'ET01.04'). Leer lassen für die oberste Ebene des Katalogs.
`year`	No	Katalogjahr — nur angeben, wenn ausdrücklich eine bestimmte Fassung gebraucht wird. Leer lassen (empfohlen): dann kommt die jüngste Fassung, in der es den Kode gibt, auch für inzwischen entfallene Kodes; welcher Jahrgang das ist, steht in 'year' der Antwort.

Output Schema

Name	Required	Description
`info`	No	Was über den Jahrgang zu wissen ist, etwa «Version 2026» (ICD-10-GM 2027) oder «Vorabfassung». Null ohne.
`year`	No	Katalogjahr, aus dem alle Daten dieser Antwort stammen.
`focus`	No	Der abgefragte Kode mit allen Detaildaten. Null bei einer Suche und beim Katalog-Einstieg (leerer Kode).
`items`	No	Die Kodeliste der Antwort: bei einer Abfrage die direkt untergeordneten Kodes von 'focus' (bzw. die oberste Ebene bei leerem Kode), bei einer Suche die Treffer.
`parents`	No	Übergeordnete Kodes von 'focus' als Pfad von der obersten Ebene abwärts (Brotkrumen). Leer bei einer Suche und beim Katalog-Einstieg.
`interpretation`	No	Nur bei einer Suche: wie die Suche die Anfrage gelesen hat. Null außerhalb der Suche.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / year / description

Previous value: -"Katalogjahr (z. B. 2027). Leer lassen für das aktuellste verfügbare Jahr."New value: +"Katalogjahr — nur angeben, wenn ausdrücklich eine bestimmte Fassung gebraucht wird. Leer lassen (empfohlen): dann kommt die jüngste Fassung, in der es den Kode gibt, auch für inzwischen entfallene Kodes; welcher Jahrgang das ist, steht in 'year' der Antwort."

Changed1 schema field changedOct 29, 2026

addedOutput schema / properties / info

Added value: +{
+  "description": "Was über den Jahrgang zu wissen ist, etwa «Version 2026» (ICD-10-GM 2027) oder «Vorabfassung». Null ohne.",
+  "properties": {
+    "subname": {
+      "description": "Zusatz zum Namen des Jahrgangs, etwa «Version 2026» oder «Vorabfassung». Null ohne Zusatz.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "subnameComment": {
+      "description": "Erläuterung zum Zusatz in einem Satz oder zwei. Null ohne Erläuterung.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

AddedOct 29, 2026

TDQS

A3.7/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

All DRGSystem — German medical coding catalogs tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?