Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

create_sales_document

Creates invoices, quotations, credit notes, order confirmations, delivery notes, or dunnings as drafts, with an option to finalize them when requested.

Instructions

Create an invoice, quotation, credit note or one of their relatives.

Writes to the account. One API call, never retried, so a failure that might have gone through has to be checked with search_vouchers.

A draft can still be edited or deleted in the web app. finalize issues it instead and the API cannot take that back. Set it only when the user asked to issue the document, never on your own initiative. It needs confirm too.

Each kind wants one thing of its own: shipping_date for an invoice, order confirmation and delivery note, expiration_date for a quotation, preceding_sales_voucher_id for a dunning.

Totals are added up by the API from the lines.

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": {
      "document_type": "<document_type>",
      "contact_id": "<contact_id>",
      "voucher_date": "<voucher_date>",
      "items": "<items>"
    },
    "name": "create_sales_document"
  }
}

Input Schema

Name	Required	Description	Default
`items`	Yes	The lines of the document.
`title`	No	Heading. The account's default is used if unset.
`remark`	No	Text below the lines.
`confirm`	No	Required only for finalize. Ignored otherwise.
`currency`	No	ISO currency code.	EUR
`finalize`	No	Issue it instead of drafting it. Only when the user asked for that. Needs confirm.
`tax_type`	No	Whether the line prices are before or after tax. 'vatfree' is for a document that carries none.	net
`contact_id`	Yes	Who the document is for, by id from search_contacts. A one-time address is not supported: create the contact.
`introduction`	No	Text above the lines.
`voucher_date`	Yes	The date on the document, as YYYY-MM-DD.
`document_type`	Yes	What to create. A down payment invoice cannot be created through the API at all.
`shipping_date`	No	When it was delivered or performed, as YYYY-MM-DD. Required for an invoice, order confirmation and delivery note.
`expiration_date`	No	How long a quotation stands, as YYYY-MM-DD. Required for one.
`preceding_sales_voucher_id`	No	The finalized document this one follows, for example the quotation an invoice comes from. Required for a dunning.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.4Nov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: the call writes to the account, is never retried, and a failure may have actually gone through, so it must be verified with search_vouchers — this gives real meaning to idempotentHint=false. It also contrasts the reversible draft state (editable/deletable in the web app) with the irreversible finalize, which is exactly the cost-of-error information an agent needs.

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?

Front-loaded with what the tool does, then the failure/idempotency warning, then the finalize hazard, then per-type field requirements. Each paragraph covers a distinct decision the agent must make; nothing is redundant with the schema text.

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 14-parameter mutation with no output schema, the description covers creation semantics, the destructive finalize path, per-type prerequisites, and the write/retry model. The remaining gap is that it never says what comes back (e.g. the new voucher id) even though there is no output schema to convey that.

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 already 100%, so a 3 is the floor; the description earns more by stating cross-parameter conditional requirements not obvious from the schema — shipping_date for invoice/order-confirmation/delivery-note, expiration_date for quotation, preceding_sales_voucher_id for dunning — and by noting the API sums totals from the lines so no total is passed.

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 concrete verb and resource ('Create an invoice, quotation, credit note or one of their relatives') and names the full enumeration of document kinds. An agent can immediately tell this is the sales-document creation path, distinct from the generic create_voucher sibling.

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?

Gives explicit when/when-not guidance for the highest-risk option: finalize must be set only when the user asked to issue, never on the agent's own initiative, and requires confirm. It also tells the agent how to recover from a failure (check with search_vouchers) and which per-type field each document kind demands. It stops short of routing to alternatives like create_voucher, which is the only real gap.

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