Skip to main content
Glama
Sign In
nkfix-mcp

nkfix-mcp

by ChriRas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Abrechnung vorprüfen

precheck_statement
Read-only

Checks whether a utility cost statement can be created for a tenant and period: missing invoices, meter readings, overlaps with existing statements, and the billing deadline. Makes no changes.

Instructions

Prüft, ob sich eine Nebenkostenabrechnung für den Mieter und Zeitraum erstellen lässt: fehlende Rechnungen und Zählerstände, Überschneidung mit bestehenden Abrechnungen, Abrechnungsfrist. Ein Ende in der Zukunft kürzt NebenkostenFix auf heute. Erstellt keine Abrechnung und ändert nichts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tenant_id": "<tenant_id>",
      "start_date": "<start_date>",
      "end_date": "<end_date>"
    },
    "name": "precheck_statement"
  }
}

Input Schema

NameRequiredDescriptionDefault
end_dateYesEnde des Abrechnungszeitraums, YYYY-MM-DD
tenant_idYesID des Mieters, siehe Werkzeug list_tenants
start_dateYesBeginn des Abrechnungszeitraums, YYYY-MM-DD
cost_category_idsNoKostenarten, die abgerechnet werden sollen. Wirkt nur auf die Prüfung auf Überschneidung mit bestehenden Abrechnungen; Zähler und Rechnungen werden immer für alle Kostenarten geprüft.

Output Schema

NameRequiredDescriptionDefault
checksYes
blockedYesmindestens eine blockierende Prüfung ist nicht in Ordnung
overallYesexcellent, acceptable, warning oder no_meters (nichts zu prüfen); warning umfasst Blockaden und bloße Hinweise
checked_untilYesEnde des geprüften Zeitraums; ein Ende in der Zukunft kürzt NebenkostenFix auf heute

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description corroborates rather than contradicts them by stating nothing is created or changed. It adds genuinely non-obvious behavior beyond the annotations: a future end date is silently clamped to today, and the enumerated check set tells the agent what the response is about. It stops short of saying what happens on failure or whether results are blocking.

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?

Two sentences, front-loaded with the purpose, and the negative constraint is placed last where it reads as a guard clause. The middle sentence is a dense colon-list, but every clause carries information the agent needs.

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

Completeness5/5

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

For a read-only precheck with an output schema, the description covers what is validated, the date-normalization side effect, and the no-mutation guarantee, which is everything needed to call it correctly. Return-value structure is covered by the output schema, so its absence from the description is not a gap.

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

Parameters4/5

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 real meaning beyond the schema: end_date values in the future are normalized to today, which an agent cannot learn from the schema alone. It does not discuss tenant_id or cost_category_ids, though the schema already explains that cost_category_ids only affects the overlap check.

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

Purpose5/5

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

The description names a specific verb (prueft/pruefen) tied to a specific resource (Nebenkostenabrechnung for a tenant and period) and enumerates the three checks performed: missing invoices/meter readings, overlap with existing statements, and the billing deadline. It also explicitly states what the tool is not ("Erstellt keine Abrechnung"), which cleanly separates it from get_statement and the record_* siblings.

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

Usage Guidelines4/5

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

The description makes the use case clear: validate feasibility before actually billing, and it rules out the write path with "Erstellt keine Abrechnung und aendert nichts." It does not name a specific sibling to use instead (e.g. get_statement for reading already-created statements), so the when-to-use guidance is strong but not fully routed.

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

Deploy Server

Other Tools