stub

Save client

save_client

Create or update a customer. Pass an id to update that customer; omit id to create a new one. Returns the new client id on create. Updating an existing customer with an opening date later than its own earliest invoice or receipt is refused, unwritten, with code confirm-required until the same call is repeated with confirm true. To create/update many at once, send an items array — one all-or-nothing transaction with a single ledger recompute; each item with an id updates, each without creates.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Client id. Present → update that client; omit → create a new one.
`city`	No	City.
`name`	No	Display name / description of the client.
`email`	No	Client email address.
`items`	No	Vector of client objects to create/update in one all-or-nothing batch. Preferred over repeated calls. Each item with an id updates; each without creates.
`hidden`	No	Whether this client is hidden from lists.
`suburb`	No	Suburb or district.
`address`	No	Street address line 1.
`confirm`	No	PROD-1950: required only to save an opening date that is LATER than the customer's own earliest invoice or receipt. Without it that one case is refused, unwritten, with code confirm-required plus earliesttransactiondate and transactionsbefore, so the caller can show what the date would exclude from the debtors balance and let the user override it.
`country`	No	Client country (ISO code or name).
`starred`	No	Whether this client is marked as a favourite.
`address2`	No	Street address line 2.
`archived`	No	Whether this client is archived. Archiving is a status flag only: the server stores it and still returns archived clients on every list, report and total. The apps filter on it.
`vatnumber`	No	VAT / tax registration number.
`postalcode`	No	Postal or ZIP code.
`contactname`	No	Name of the primary contact person.
`openingdate`	No	Date the opening balance applies from (ISO 8601).
`contactemail`	No	Email of the primary contact person.
`customercode`	No	Your internal customer/account code for this client.
`contactnumber`	No	Phone number of the primary contact person.
`openingbalance`	No	Opening balance amount carried for this client at openingdate.
`registrationnumber`	No	Business registration number.
`clearopeningbalance`	No	Reserved, mirrors update_bank_account: when true the opening-date confirmation below is not asked.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 23, 2026

changedInput schema / properties / archived / description

Previous value: -"Whether this client is archived (hidden from active lists)."New value: +"Whether this client is archived. Archiving is a status flag only: the server stores it and still returns archived clients on every list, report and total. The apps filter on it."

addedInput schema / properties / clearopeningbalance

Added value: +{
+  "description": "Reserved, mirrors update_bank_account: when true the opening-date confirmation below is not asked.",
+  "type": "boolean"
+}

addedInput schema / properties / confirm

Added value: +{
+  "description": "PROD-1950: required only to save an opening date that is LATER than the customer's own earliest invoice or receipt. Without it that one case is refused, unwritten, with code confirm-required plus earliesttransactiondate and transactionsbefore, so the caller can show what the date would exclude from the debtors balance and let the user override it.",
+  "type": "boolean"
+}

changedInput schema / properties / items / items / properties / archived / description

Previous value: -"Whether this client is archived (hidden from active lists)."New value: +"Whether this client is archived. Archiving is a status flag only: the server stores it and still returns archived clients on every list, report and total. The apps filter on it."

First observedSep 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation nature is already known. The description adds critical behavioral context beyond that: the confirm-required refusal with code confirm-required, the all-or-nothing batch transaction with single ledger recompute, and the return of the new client id on create. These are valuable disclosures not captured in annotations.

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

Conciseness4/5

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

The description is moderately detailed but every sentence carries information: the id behavior, the return value, the confirm-required edge case, and the batch transaction. There is slight redundancy between the opening line and the items description, but overall it is tightly written and front-loads the most important operational detail (id presence).

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 tool's complexity (23 parameters, all optional), the description covers the key behavioral quirks that an agent must know: the confirm flow, batch semantics, and return value. There is no output schema, but the description states the create return value. It does not detail the update or batch return format, but the core behaviors are well covered, making it sufficient for correct invocation.

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 already documents every parameter. The description adds meaning beyond that by explaining the semantics of the id parameter (present vs omitted), the items array behavior, and the confirm parameter's role in the refusal flow. This is exactly the kind of contextual explanation that helps an agent use the parameters 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?

The description states a specific verb and resource ('Create or update a customer') and explains the id-dependent behavior, which clearly distinguishes it from sibling tools like save_supplier or save_product. It immediately tells an agent what resource this operates on and how the core operation works.

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 provides clear conditional usage: pass id to update, omit to create; use the items array for batch operations; and use confirm when the opening date is later than the earliest transaction. It does not explicitly name alternatives, but there is no create_client sibling, so this is the only client save tool. The guidance is actionable and complete for the tool's own variants.

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

All stub 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.

Resources

Need Help?