Kema Invoice

Upsert client billing profile

upsert_invoice_client_profile

Create or update a company's invoicing defaults (payment terms, delivery channel, invoice prefix). These defaults pre-fill future invoices for that client.

Input Schema

TableJSON Schema

Name	Required	Description
`company_id`	Yes	Company UUID (use list_companies to resolve).
`payment_terms`	No	Default payment terms for this client's invoices. Defaults to Net-30 on creation.
`invoice_prefix`	No	Custom invoice number prefix (max 10 chars, uppercase letters, digits and hyphens); null to use the tenant default.
`delivery_channel`	No	How invoices reach this client: Email, e-Invoice or Manual. Defaults to Email on creation.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Profile UUID.
`company`	Yes	Company name, null when not resolvable.
`company_id`	Yes	Company UUID.
`payment_terms`	Yes	Payment terms: Net-15, Net-30, Net-60, Net-90 or Due on Receipt.
`invoice_prefix`	Yes	Custom invoice number prefix, null for the tenant default.
`delivery_channel`	Yes	Delivery channel: Email, e-Invoice or Manual.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 7, 2026

addedInput schema / properties / company_id / description

Added value: +"Company UUID (use list_companies to resolve)."

addedInput schema / properties / delivery_channel / description

Added value: +"How invoices reach this client: Email, e-Invoice or Manual. Defaults to Email on creation."

addedInput schema / properties / invoice_prefix / description

Added value: +"Custom invoice number prefix (max 10 chars, uppercase letters, digits and hyphens); null to use the tenant default."

addedInput schema / properties / payment_terms / description

Added value: +"Default payment terms for this client's invoices. Defaults to Net-30 on creation."

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": "Company name, null when not resolvable."
+    },
+    "company_id": {
+      "description": "Company UUID.",
+      "type": "string"
+    },
+    "delivery_channel": {
+      "description": "Delivery channel: Email, e-Invoice or Manual.",
+      "type": "string"
+    },
+    "id": {
+      "description": "Profile UUID.",
+      "type": "string"
+    },
+    "invoice_prefix": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Custom invoice number prefix, null for the tenant default."
+    },
+    "payment_terms": {
+      "description": "Payment terms: Net-15, Net-30, Net-60, Net-90 or Due on Receipt.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "company_id",
+    "company",
+    "payment_terms",
+    "delivery_channel",
+    "invoice_prefix"
+  ],
+  "type": "object"
+}

First observedSep 7, 2026

TDQS

A4/5.0

Behavior4/5

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

The annotations (readOnlyHint false, destructiveHint false) indicate a write but non-destructive operation; the description adds that these defaults 'pre-fill future invoices', revealing a persistent side effect beyond what the annotations convey. This is useful and consistent, though it does not mention idempotency or error outcomes.

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 two concise sentences, directly stating the action, object, and effect without unnecessary words. It is well-structured and easy to parse.

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?

For a straightforward upsert tool, the description covers purpose and a key side effect. It does not mention expected output or failure modes, but since an output schema exists (as indicated by context signals), that omission is acceptable. The description is sufficiently complete for an agent to use the tool correctly.

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?

The schema descriptions cover 100% of parameters, so the baseline is 3. The description text only reiterates the field names without adding new meaning beyond what the schema already states (e.g., payment terms, delivery channel, invoice prefix). No additional clarifying details are provided in the description.

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 explicitly states the verb 'Create or update' and the resource 'company's invoicing defaults', listing the specific fields (payment terms, delivery channel, invoice prefix) and the purpose of pre-filling future invoices. This clearly distinguishes it from sibling tools like get_invoice_client_profile or delete_invoice_client_profile.

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

Usage Guidelines3/5

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

The description implies the tool is used to set or modify billing defaults but does not explicitly state when to use it over alternatives (e.g., when to call this vs. get_invoice_client_profile). It lacks conditional guidance for the agent beyond the basic create/update semantics.

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.