Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

update_voucher

DestructiveIdempotent

Modify an existing bookkeeping voucher using its current version to prevent overwriting concurrent edits; replace line items, totals, dates, or contact details.

Instructions

Change a bookkeeping voucher that is already recorded.

Writes real accounting data. Read it with get_voucher first: it shows what is there and carries the version this needs. Two API calls. Passing items replaces every line rather than adding one.

An unchecked voucher takes new data and stays unchecked until finalize books it, which needs its number, date, contact and lines.

If the voucher changed since that read, nothing is written. One that is already paid or booked may be refused whatever the version.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "voucher_id": "<voucher_id>",
      "version": "<version>"
    },
    "name": "update_voucher"
  }
}

Input Schema

Name	Required	Description
`items`	No	Replaces every line on the voucher. The totals are recomputed to match unless you state them.
`remark`	No	New note.
`confirm`	No	Required only for finalize. Ignored otherwise.
`version`	Yes	The `version` from the record as you last read it. If the record has changed since, the update is refused instead of overwriting that change.
`due_date`	No	New due date, as YYYY-MM-DD.
`finalize`	No	Book an unchecked voucher, such as one upload_file made, by moving it to open. Only when the user asked for that. Needs confirm.
`contact_id`	No	Move it to a different contact, by id.
`voucher_id`	Yes	The voucher's Lexware id, as returned by search_vouchers. Not the voucher number a human reads off the document.
`voucher_date`	No	New document date, as YYYY-MM-DD.
`voucher_number`	No	New document number.
`total_tax_amount`	No	New total tax.
`total_gross_amount`	No	New total including tax.
`use_collective_contact`	No	True moves it to the collective contact instead of a named one. Not together with contact_id. To leave the collective contact, pass contact_id instead.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.4Nov 9, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructive=true, so the bar is lower, but the description adds real value beyond them: optimistic concurrency via `version`, the two-call read-then-write pattern, the state machine for `unchecked` vs `finalize`, and the fact that `items` replaces rather than appends. It doesn't say what happens to fields left null or what the response contains, which a 13-parameter mutation could use.

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?

Front-loaded with the core action, then the safety prerequisite, then the replacement semantics and state rules. Every sentence carries information, though the fragment-style lines ("Two API calls.") read clipped and slightly slow comprehension.

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 13-parameter destructive mutation with no output schema, the description covers the safety-critical behaviour: when a write is refused, what the version guard is, and what finalize does. It stops short of explaining partial-update semantics for the many nullable fields and what the caller gets back.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by flagging that `items` replaces every line and that the version must match the last read, both of which shape how the agent fills those parameters.

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?

"Change a bookkeeping voucher that is already recorded" gives a specific verb and resource, and "already recorded" implicitly separates it from create_voucher. The agent can tell this is an in-place mutation of an existing document without opening the schema.

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 sets a clear prerequisite (read with `get_voucher` first to obtain `version`) and states when it should not be used (paid or booked vouchers may be refused; `finalize` only when the user asked for it). It doesn't explicitly route to a sibling like create_voucher or explain when to skip an update in favour of a new record, so the guidance is strong but not exhaustive.

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