Kema Invoice

Update line item (draft)

update_invoice_item

Update a line item on a Draft invoice. Totals are recalculated automatically. Item ids come from get_invoice or add_invoice_item.

Input Schema

TableJSON Schema

Name	Required	Description
`item_id`	Yes	The line item UUID.
`quantity`	No	New quantity; null to clear (non-item lines).
`tax_rate`	No	OMIT - VAT is determined server-side by fiscal rules; only set on explicit user request, as a percent (0-100).
`line_type`	No	New line kind: 'item', 'section' or 'description'.
`unit_price`	No	New unit price excl. VAT, in the invoice currency; null to clear (non-item lines).
`description`	No	New line text (1-500 characters).

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Line item UUID.
`quantity`	Yes	Quantity, null for section/description lines.
`tax_rate`	Yes	VAT rate in percent, null for non-item lines.
`line_type`	Yes	Line kind: item, section or description.
`created_at`	Yes	Creation timestamp (ISO 8601).
`invoice_id`	Yes	Parent invoice UUID.
`line_total`	Yes	Line total incl. VAT, null for non-item lines.
`product_id`	Yes	Linked product UUID, if any.
`unit_price`	Yes	Unit price excl. VAT, null for non-item lines.
`updated_at`	Yes	Last update timestamp (ISO 8601).
`description`	Yes	Line text.
`tax_rate_key`	Yes	VAT rate key (e.g. standard, reduced), null for non-item lines.
`display_order`	Yes	0-based position on the document.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 7, 2026

addedInput schema / properties / description / description
```
Added value: +"New line text (1-500 characters)."
```
addedInput schema / properties / item_id / description
```
Added value: +"The line item UUID."
```

addedInput schema / properties / line_type / description

Added value: +"New line kind: 'item', 'section' or 'description'."

addedInput schema / properties / quantity / description

Added value: +"New quantity; null to clear (non-item lines)."

changedInput schema / properties / tax_rate / description

Previous value: -"OMIT — VAT is determined server-side by fiscal rules; only set on explicit user request."New value: +"OMIT - VAT is determined server-side by fiscal rules; only set on explicit user request, as a percent (0-100)."

addedInput schema / properties / unit_price / description

Added value: +"New unit price excl. VAT, in the invoice currency; null to clear (non-item lines)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "created_at": {
+      "description": "Creation timestamp (ISO 8601).",
+      "type": "string"
+    },
+    "description": {
+      "description": "Line text.",
+      "type": "string"
+    },
+    "display_order": {
+      "description": "0-based position on the document.",
+      "type": "number"
+    },
+    "id": {
+      "description": "Line item UUID.",
+      "type": "string"
+    },
+    "invoice_id": {
+      "description": "Parent invoice UUID.",
+      "type": "string"
+    },
+    "line_total": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Line total incl. VAT, null for non-item lines."
+    },
+    "line_type": {
+      "description": "Line kind: item, section or description.",
+      "type": "string"
+    },
+    "product_id": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Linked product UUID, if any."
+    },
+    "quantity": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Quantity, null for section/description lines."
+    },
+    "tax_rate": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "VAT rate in percent, null for non-item lines."
+    },
+    "tax_rate_key": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "VAT rate key (e.g. standard, reduced), null for non-item lines."
+    },
+    "unit_price": {
+      "anyOf": [
+        {
+          "type": "number"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Unit price excl. VAT, null for non-item lines."
+    },
+    "updated_at": {
+      "description": "Last update timestamp (ISO 8601).",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "invoice_id",
+    "line_type",
+    "description",
+    "quantity",
+    "unit_price",
+    "tax_rate",
+    "tax_rate_key",
+    "line_total",
+    "display_order",
+    "product_id",
+    "created_at",
+    "updated_at"
+  ],
+  "type": "object"
+}

First observedSep 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate this is a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds useful behavioral context by stating that totals are recalculated automatically, which is not derivable from the annotations or schema.

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 sentences with no filler. The primary purpose and draft constraint are front-loaded, followed by the useful behavior note and id-source guidance. Every sentence contributes necessary information.

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?

Given the full parameter schema, annotations, and output schema, the description is largely complete. It covers the draft restriction, automatic recalculation, and id source. It could mention that line_type can change to section/description, but the schema already documents this, so no critical gap remains.

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 description coverage is 100%, so the schema documents all parameters. The description adds value beyond the schema by explaining where item_id values come from, which directly helps the agent supply the required parameter correctly.

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 ('Update'), a specific resource ('line item on a Draft invoice'), and the draft constraint. This clearly distinguishes it from sibling tools like add_invoice_item, delete_invoice_item, and reorder_invoice_items without needing to inspect their schemas.

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?

Explicitly scopes the tool to Draft invoices and tells the agent where to obtain item ids (get_invoice or add_invoice_item). It does not explicitly enumerate when to prefer sibling tools like delete_invoice_item, but the draft-only scope and id-source guidance give a clear usage context.

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.