Skip to main content
Glama
Sign In
nkfix-mcp

nkfix-mcp

by ChriRas
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Sammelbeleg hochladen

upload_invoice_document

Uploads a receipt containing multiple invoices for a property, creating a new document without changing existing records. Use the returned document ID to record each invoice.

Instructions

Lädt einen Beleg mit mehreren Rechnungen (z. B. Jahresabrechnung der Stadtwerke) zu einer Immobilie hoch (schreibt, ändert nichts Bestehendes). Danach legst du jede Rechnung darauf mit record_invoice und invoice_document_id an.

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": {
      "property_id": "<property_id>",
      "receipt_path": "<receipt_path>"
    },
    "name": "upload_invoice_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
descriptionNo
property_idYesID der Immobilie, siehe Werkzeug list_properties
receipt_pathYesPfad der Belegdatei auf diesem Rechner (PDF, JPEG, PNG, WebP oder HEIC), z. B. ~/Belege/wasser-2025.pdf
approval_codeNoFreigabecode aus einer vorigen Antwort mit saved=false. Nur mitschicken, nachdem du dem Menschen die Bedenken gezeigt hast und er dem Speichern ausdrücklich zugestimmt hat. Nie vorab und nie von dir aus.

Output Schema

NameRequiredDescriptionDefault
idYesID des neuen Eintrags
noteYes
savedYes
concernsYeswas gegen das Speichern sprach (auch wenn trotzdem gespeichert wurde)
approval_codeNoCode für den zweiten Aufruf, falls der Mensch trotz der Bedenken speichern will

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and non-idempotent, and the description's 'schreibt, ändert nichts Bestehendes' restates the write/non-destructive profile while adding the downstream effect that invoices are attached afterwards. It does not cover what happens on re-upload of the same file (non-idempotent) or how the returned document ID is used beyond the pointer to record_invoice. The approval_code gate is explained only in the schema, not here.

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 short sentences, front-loaded with the core action and followed by the workflow implication; nothing is padded. The parenthetical example adds orienting context rather than noise.

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?

With annotations present, a 75%-covered schema and an output schema, the description covers the essential action and the mandatory next step in the workflow. The remaining gaps — duplicate/re-upload behavior and the consent/approval flow — are partly handled by the schema's approval_code description.

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 75% and the schema itself documents property_id, receipt_path and the approval_code consent rule in detail, so the description adds little parameter meaning. It only hints at the produced invoice_document_id, which is an output rather than an input. Baseline 3 is appropriate since the schema carries the semantics.

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?

States a specific verb and resource ('Lädt einen Beleg ... zu einer Immobilie hoch') and narrows the scope to a multi-invoice receipt such as an annual utility statement, which distinguishes it from the sibling record_invoice. The follow-up relationship to record_invoice is spelled out, so an agent can place the tool in the pipeline without opening the schema.

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?

Gives an explicit sequence: upload the collection receipt first, then record each individual invoice against it using record_invoice and invoice_document_id. That is clear when-to-use guidance with a named alternative, but there is no explicit exclusion (e.g. what to do for a single invoice or when a duplicate receipt already exists).

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