Kema Invoice

List available provisions

list_available_provisions

Read-only

List PAID provisions (avances sur honoraires, retainers) that have not been applied to a final invoice yet - the deductible client credit. Without matter_id, lists the standalone retainers (no matter), which is the normal case in Kema Invoice; with matter_id, lists that matter's retainers. Use before apply_provisions_to_invoice.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`matter_id`	No	Matter (dossier) UUID to restrict to; omit to list standalone retainers, the normal case in Kema Invoice.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes	Paid provisions not yet applied to an invoice (standalone, or of the given matter), most recently paid first.
`total`	Yes	Number of provisions returned.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 8, 2026

changedInput schema / properties / matter_id / description

Previous value: -"The matter (dossier) UUID."New value: +"Matter (dossier) UUID to restrict to; omit to list standalone retainers, the normal case in Kema Invoice."

removedInput schema / required
```
Removed value: -[
-  "matter_id"
-]
```

changedOutput schema / properties / items / description

Previous value: -"Paid provisions of the matter not yet applied to an invoice, most recently paid first."New value: +"Paid provisions not yet applied to an invoice (standalone, or of the given matter), most recently paid first."

Changed1 schema field changedSep 7, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "items": {
+      "description": "Paid provisions of the matter not yet applied to an invoice, most recently paid first.",
+      "items": {
+        "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"
+      },
+      "type": "array"
+    },
+    "total": {
+      "description": "Number of provisions returned.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "items",
+    "total"
+  ],
+  "type": "object"
+}

First observedSep 7, 2026

TDQS

A4.8/5.0

Behavior4/5

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

The readOnlyHint annotation already covers the read-only nature, and the description's use of 'List' aligns with that. The description goes beyond annotations by explaining what 'available' means (not applied to final invoices), adding domain context. However, it does not explicitly state side-effect-free behavior, but that is implied and consistent with the annotation.

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?

The description is concise yet informative, explaining both the resource and the parameter behavior in a few sentences. No redundant or vague wording; all sentences add value.

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 single optional parameter and the existence of an output schema (not shown but implied), the description provides sufficient context to call the tool correctly. It covers the default case, the filter case, and the intended usage sequence. No missing critical information for a simple list operation.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description covers matter_id fully, explaining its purpose (restrict to a matter) and the default when omitted. The description reinforces this by stating the normal case. 100% parameter coverage with meaningful explanation.

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 clearly states the specific action ('List') and the resource ('paid provisions' not yet applied to final invoices), and clarifies the domain meaning ('deductible client credit'). It also distinguishes the tool from siblings like apply_provisions_to_invoice by specifying the filter behavior.

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?

The description explicitly explains the single optional parameter (matter_id) and its default behavior (standalone retainers, the normal case). It also directly advises to use this tool before apply_provisions_to_invoice, giving clear when-to-use guidance.

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.