offene_postenNennt die Rechnungen, deren Zahlungsziel abgelaufen ist, mit Tagen seit Fälligkeit, offenem Betrag und der Mahnstufe, die nach den Einstellungen des Betriebs fällig wäre. Für „wer schuldet mir noch Geld?" und die Vorbereitung eines Mahnlaufs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Höchstzahl der Treffer, 1 bis 100. Vorgabe 25. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, and the description adds behavioral context: it returns days since due, open amount, and a computed dunning level that would be due according to business settings, implying no dunning action is actually triggered. The title also warns 'Konto nötig', which is useful auth context.
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 carry all necessary information: the first explains what is returned, the second states the intended use cases. No filler or repetition; both sentences earn their 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?
The tool is simple (one optional parameter, no output schema), and the description adequately covers the return content and purpose. With no output schema, it is valuable that the description names the key output fields, and the account requirement is disclosed in the title.
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 only parameter, limit, is fully documented in the schema with range and default. The description adds no additional parameter-specific meaning, but with 100% schema coverage, 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 verb ('Nennt') and resource ('die Rechnungen, deren Zahlungsziel abgelaufen ist'), and adds the exact criteria and returned fields. This clearly distinguishes it from siblings like rechnungen_suchen or rechnung_lesen, which are about searching or reading invoices generally, not specifically overdue ones with dunning 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 explicitly names two use cases: 'wer schuldet mir noch Geld?' and preparing a dunning run (Mahnlauf). It does not mention alternatives or when not to use this tool, but the context is clear enough for an agent to choose it for overdue-invoice scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target distinct resources (customers, services, invoices, payments, legal checks), but rechnung_erstellen vs. leistungen_abrechnen both create invoices and rechnung_pruefen vs. pflichtangaben_pruefen both validate invoices, though with different inputs and scopes. The descriptions are detailed enough to resolve ambiguity after careful reading.
The dominant pattern is object_verb (kunden_suchen, rechnung_erstellen, zahlung_erfassen), but several names are noun phrases (offene_posten, leistungen_offen, umsatzsteuer_aufstellung) or noun_noun (rechnung_datei). This mixed convention is still readable but lacks a uniform verb-based structure.
At 18 tools, the server sits in the borderline-heavy range (16-25). The domain of German e-invoicing is broad, but the large number is not fully justified by tool specialization, as some functions (e.g., multiple validation tools) could be consolidated.
The surface covers the core lifecycle of services, invoicing, payment recording, and validation, but notable operations are missing: creating credit notes (explicitly referenced in zahlung_erfassen), managing customers, and updating/cancelling invoices. These gaps can lead to dead ends in common workflows like handling overpayments or customer changes.