Kema Invoice

Update company

update_company

Update fields of an existing client company (name, contact info, address, VAT number, SIREN). Only provided fields change. Fixing the VAT number / SIREN / address here is often required before an invoice for this client can be certified.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	New city.
`name`	No	New display name.
`email`	No	New billing email address.
`phone`	No	New phone number, any format.
`siren`	No	French SIREN, 9 digits.
`tax_id`	No	VAT number, e.g. FR12345678901.
`country`	No	ISO 3166-1 alpha-2 country code, e.g. FR.
`website`	No	New website URL, including the scheme (https://).
`company_id`	Yes	The company UUID to update.
`postal_code`	No	New postal code.
`street_address`	No	New street address (number and street).

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Company UUID.
`name`	Yes	Display name.
`email`	Yes	Billing email.
`siren`	Yes	French SIREN (9 digits).
`tax_id`	Yes	VAT number.

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedSep 7, 2026

addedInput schema / properties / city / description
```
Added value: +"New city."
```
addedInput schema / properties / company_id / description
```
Added value: +"The company UUID to update."
```

changedInput schema / properties / country / description

Previous value: -"ISO country, e.g. FR."New value: +"ISO 3166-1 alpha-2 country code, e.g. FR."

addedInput schema / properties / email / description
```
Added value: +"New billing email address."
```
addedInput schema / properties / name / description
```
Added value: +"New display name."
```
addedInput schema / properties / phone / description
```
Added value: +"New phone number, any format."
```
addedInput schema / properties / postal_code / description
```
Added value: +"New postal code."
```
addedInput schema / properties / street_address / description
```
Added value: +"New street address (number and street)."
```

changedInput schema / properties / tax_id / description

Previous value: -"VAT number."New value: +"VAT number, e.g. FR12345678901."

addedInput schema / properties / website / description

Added value: +"New website URL, including the scheme (https://)."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "email": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Billing email."
+    },
+    "id": {
+      "description": "Company UUID.",
+      "type": "string"
+    },
+    "name": {
+      "description": "Display name.",
+      "type": "string"
+    },
+    "siren": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "French SIREN (9 digits)."
+    },
+    "tax_id": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "VAT number."
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "email",
+    "tax_id",
+    "siren"
+  ],
+  "type": "object"
+}

First observedSep 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The description explicitly states 'Only provided fields change', which clarifies the partial update behavior. This goes beyond the annotations (readOnlyHint false, destructiveHint false) by explaining the update semantics. It does not mention potential side effects, but the core behavior is well described.

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 sentences long, with no redundant information. It efficiently conveys the purpose, the partial update behavior, and a practical use case, making it well-structured and easy to absorb.

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?

The description includes all essential context: the action (update), the target (existing company), the fields involved, the partial update rule, and a real-world scenario (invoice certification). Combined with the full schema descriptions and annotations, nothing critical is missing for an agent to decide when and how to invoke this tool.

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 already provides descriptions for all 11 parameters (100% coverage), so the parameter semantics are fully handled by the schema. The description mentions the key field categories but does not add meaning beyond what the schema already states, hence a baseline score of 3.

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 tool updates an existing company and lists the specific fields (name, contact info, address, VAT number, SIREN). This distinguishes it from create_company, delete_company, and get_company, making the purpose unambiguous.

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?

The description explains when to use the tool, especially noting that fixing VAT/SIREN/address is often required before invoice certification. It does not explicitly contrast with sibling tools, but the partial update behavior and use case provide strong practical 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.