Skip to main content
Glama
Sign In
Unofficial Lexware Office MCP Server

Unofficial Lexware Office MCP Server

by benethos-hub
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

create_voucher

Records a bookkeeping voucher in Lexware Office with line items, tax details, and posting categories, booking it immediately to the account.

Instructions

Record a bookkeeping voucher in the account.

Writes real accounting data, and the API cannot take it back: there is no way to delete a voucher here. Correcting one is a job for the web app. Confirm the organization with get_profile first. One API call, never retried.

Every line needs a posting category id, from get_master_data with kind 'posting-categories'. Totals are added up from the lines unless stated. It is booked immediately and no status can be asked for. To record a receipt for review instead, use upload_file, which files it as an unchecked purchase invoice.

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_type": "<voucher_type>",
      "voucher_date": "<voucher_date>",
      "tax_type": "<tax_type>",
      "items": "<items>",
      "voucher_number": "<voucher_number>"
    },
    "name": "create_voucher"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsYesThe lines this voucher books. Every line names the posting category it belongs to. At least one is required.
remarkNoA note kept with the voucher.
due_dateNoWhen payment is due, as YYYY-MM-DD.
tax_typeYes'gross' means the line amounts include tax, 'net' means they do not, 'vatfree' means there is none. The API checks the lines against this and refuses a mismatch.
contact_idNoThe customer or vendor this belongs to, by id from search_contacts. Leave unset to book against the collective contact instead of a named one.
voucher_dateYesThe date on the document, as YYYY-MM-DD.
voucher_typeYesWhat is being booked: a sales invoice or credit note is money owed to the account, a purchase invoice or credit note is money the account owes.
shipping_dateNoDelivery or service date, as YYYY-MM-DD.
voucher_numberYesThe number on the document being recorded, for example the supplier's invoice number. Required by the API for every voucher type.
total_tax_amountNoThe total tax. Also added up from the lines if unset.
total_gross_amountNoThe total including tax. Leave unset to have it added up from the lines, which is what the API expects it to equal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.4

TDQS

A4.5/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: the write is irreversible, there is no delete path in this API, correction requires the web app, the call must never be retried, and the voucher is booked immediately with no queryable status. `idempotentHint: false` is reinforced rather than contradicted by "never retried." The only mild tension is `destructiveHint: false` alongside "the API cannot take it back," though that hint reasonably refers to deletion of existing data; the description still leaves the success response shape (e.g. whether a voucher id comes back) unexplained, which matters for follow-up calls like `attach_file_to_voucher`.

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 most consequential fact — irreversible write — is front-loaded and bolded, and the paragraph that follows sequences prerequisites, total behavior, and the alternative. It runs long and repeats the category-id sourcing instruction that also appears in both the item and top-level schema, which is minor redundancy rather than waste.

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 an 11-parameter, non-idempotent mutation with no output schema, the definition covers the high-risk facts an agent needs before calling: irreversibility, no retry, no status polling, required category ids, and the review-flow alternative. The remaining gap is the return value — nothing tells the agent what it gets back on success, which is the natural input to `attach_file_to_voucher` or `get_voucher`.

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?

With 100% schema description coverage the baseline is 3, and the description earns an increment by stating cross-field behavior the schema only documents piecemeal: "Every line needs a posting category **id**, from `get_master_data`..." and "Totals are added up from the lines unless stated." It does not, however, add anything about required-vs-optional defaults or the `remark`/`due_date`/`shipping_date` fields beyond what the schema already states.

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?

Opens with a specific verb+resource: "Record a bookkeeping voucher in the account." It immediately distinguishes itself from the two nearest siblings by naming them — `upload_file` for receipts-needing-review and the web app for corrections — so an agent can route correctly without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit prerequisites (`get_profile` to confirm the organization, `get_master_data` with kind 'posting-categories' for category ids) and an explicit alternative for the common adjacent intent: "To record a receipt for review instead, use `upload_file`." Both when-to-use and when-not-to-use are covered with named tools.

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

Deploy Server

Other Tools