Kema Invoice

Mark provision paid

mark_provision_paid

Mark an issued provision (status Sent/Overdue) as Paid. A paid provision becomes a client credit that can be deducted from that client's final invoice with apply_provisions_to_invoice.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`paid_at`	No	Payment timestamp (ISO 8601, e.g. 2026-09-07T10:00:00Z). Defaults to now.
`invoice_id`	Yes	The Sent or Overdue provision UUID.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Provision UUID.
`matter`	Yes	Matter (dossier) name, null when unknown.
`status`	Yes	Document status: Draft, Sent, Paid, Overdue, Cancelled, Rectified, Accepted, Rejected or Expired.
`company`	Yes	Client company name, null when unknown.
`paid_at`	Yes	Payment timestamp (ISO 8601), null while unpaid.
`currency`	Yes	ISO 4217 currency code (EUR, USD, GBP or CHF).
`due_date`	Yes	Due date, YYYY-MM-DD.
`issue_date`	Yes	Issue date, YYYY-MM-DD.
`gross_total`	Yes	Total incl. VAT, in the document currency.
`invoice_number`	Yes	Provision number (PROV series).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 7, 2026

changedInput schema / properties / invoice_id / description

Previous value: -"The provision UUID."New value: +"The Sent or Overdue provision UUID."

changedInput schema / properties / paid_at / description

Previous value: -"Payment timestamp (ISO 8601). Defaults to now."New value: +"Payment timestamp (ISO 8601, e.g. 2026-09-07T10:00:00Z). Defaults to now."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "company": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Client company name, null when unknown."
+    },
+    "currency": {
+      "description": "ISO 4217 currency code (EUR, USD, GBP or CHF).",
+      "type": "string"
+    },
+    "due_date": {
+      "description": "Due date, YYYY-MM-DD.",
+      "type": "string"
+    },
+    "gross_total": {
+      "description": "Total incl. VAT, in the document currency.",
+      "type": "number"
+    },
+    "id": {
+      "description": "Provision UUID.",
+      "type": "string"
+    },
+    "invoice_number": {
+      "description": "Provision number (PROV series).",
+      "type": "string"
+    },
+    "issue_date": {
+      "description": "Issue date, YYYY-MM-DD.",
+      "type": "string"
+    },
+    "matter": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Matter (dossier) name, null when unknown."
+    },
+    "paid_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Payment timestamp (ISO 8601), null while unpaid."
+    },
+    "status": {
+      "description": "Document status: Draft, Sent, Paid, Overdue, Cancelled, Rectified, Accepted, Rejected or Expired.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "invoice_number",
+    "status",
+    "matter",
+    "company",
+    "issue_date",
+    "due_date",
+    "paid_at",
+    "currency",
+    "gross_total"
+  ],
+  "type": "object"
+}

First observedSep 7, 2026

TDQS

A4.7/5.0

Behavior4/5

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

The description explains the main side effect (creates a client credit) and implies a write operation. It does not mention reversibility or other potential effects, but annotations are sparse (readOnly=false, destructive=false), so the description carries the burden and covers the key behavior well.

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

Conciseness5/5

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

Two clear, tight sentences with no redundant wording. Efficiently conveys purpose, conditions, and consequence.

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?

Given the simple two-parameter schema and the sibling context, the description is complete. It explains the outcome (credit) and the relationship to apply_provisions_to_invoice, leaving no ambiguity about the tool's role.

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?

The description adds default behavior for paid_at (defaults to now) and identifies invoice_id as the provision UUID. The schema already provides detailed format and descriptions for both parameters, so the description adds marginal but useful context beyond the schema.

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?

Clearly states the action (mark as paid), the target (provision), the applicable statuses (Sent/Overdue), and the resulting effect (becomes client credit). Distinguishes it from sibling tools like mark_invoice_paid.

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

Usage Guidelines5/5

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

Explicitly defines when to use (for Sent/Overdue provisions) and explains the consequential credit that can be applied via apply_provisions_to_invoice. Provides enough context to select this tool over alternatives.

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

All Kema Invoice 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.