Report which server is running: name, version, transport, Python and MCP library versions and uptime, without an API call. With details, also whether Lexware answers and accepts the key, at most one API call every 60 seconds, and whether the tool policy file is loaded. If it is not, no other tool is offered. An answer holds for the moment it was given: after the settings change, call it again rather than rely on an earlier one.

Show which Lexware Office account this server is connected to.

One API call. Returns the organization, company name, tax setup and small-business status.

Call it before anything that changes data, so the organization is confirmed rather than assumed. It doubles as the connection check: if it succeeds, the API key works.

Find contacts by name, email address, number or role.

One API call per page. This is how a name becomes an id: every tool taking a contact_id expects one from here, never a guessed value. Use get_contact afterwards for the full record with its addresses.

Rows carry the id, name, customer and vendor numbers and one way to get in touch. A row marked archived is no longer in active use.

Filters combine with AND. Giving none lists the account in name order. Read page before asking for another one.

Read one contact in full, by id.

Returns the complete record: roles and their numbers, billing and shipping addresses, all email addresses and phone numbers, the note and the version. Costs one API call.

Use search_contacts when you have a name rather than an id. Read this before updating a contact, because update_contact needs the version it reports.

Create a new customer or vendor in the account.

Writes real accounting data, and the API cannot take it back: there is no call that deletes a contact, though the web app does. Confirm the organization with get_profile first, and search the name with search_contacts: Lexware allows a second contact with the same name, and later documents then attach to either at random. One API call.

Returns the id and version, not the record. Lexware assigns the customer and vendor numbers, so read the contact back to see them.

Change an existing contact. Only the fields you give are changed.

Writes real accounting data. Read the contact with get_contact first: it shows what is there and carries the version this needs. Two API calls.

If the contact changed since that read, nothing is written and the error says so. Read it again and decide what to do with the change you would have overwritten.

List articles, filtered by number, barcode or kind.

One API call, one page. Rows carry the id, title, number, type, unit and price.

There is no search by title. The API filters on these three fields and silently ignores anything else, so finding an article by name means paging through the list and reading the titles.

Both filters match in full, not by fragment.

Read one article in full, by id.

One API call. Returns the title, description, note, unit, type, the price block and the version.

Use search_articles when you have an article number or a barcode rather than an id. Read this before update_article, which needs the version it reports. An unknown id answers with an error, not an empty record.

The price carries a net and a gross figure with the tax rate between them. leadingPrice says which of the two was entered and which the API computed.

Add an article to the catalogue.

Writes to the account. One API call, and it is not retried.

Returns the new id and version, not the record. Read it back with get_article to see the price the API computed from the one given.

Unlike a voucher, an article can be removed again with delete_article.

Change an article. Only the fields you give are changed.

Read it with get_article first: that shows what is there and carries the version this needs. Two API calls.

If the article changed since that read, nothing is written and the error says so.

Giving price replaces the side named by leading_price and leaves the other for the API to recompute.

Delete an article. The API has no way back.

The record is removed, not archived: reading it afterwards is a "not found". One API call, and only once confirm is true.

Documents that already quote this article keep their line items, which hold their own copy of the text and the price.

Find invoices, credit notes, quotations and bookkeeping vouchers.

One API call per page. The only way to turn a question about the books into the ids get_voucher, get_payments and the document tools need. Starting from a customer name, get the contact id from search_contacts first and pass it here.

Rows carry id, type, status, number, dates, contact name, total and open amount. A row marked archived is filed away.

Narrow voucher_type and voucher_status to keep the answer small. voucher_status 'open' or 'overdue' answers "what is still outstanding" without paging through everything.

Read one bookkeeping voucher, by id or by its document number.

One API call. Returns the booked amounts, tax type, the posting category of every line, the contact and the version.

Prefer the id. A number is unique only by convention, and search_vouchers finds one across every document type.

For whether it has been paid, use get_payments with the same id.

Show whether a voucher has been paid, and what is still open.

Returns the payment status, the amount still outstanding, the currency and the individual payments recorded against it. Costs one API call.

Takes the id of the voucher, not of a payment. An openAmount of 0 is the answer to "is it settled" and is reported rather than omitted.

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.

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.

Read one sales document in full: an invoice, quotation or their kin.

One API call. Returns the recipient, the line items with their unit prices, the totals, the tax breakdown and the version.

document_type has to match the id. A mismatch answers "not found", exactly as a wrong id does.

A draft reads in full with voucherStatus draft: nothing has been rendered yet, and download_document refuses it.

For a bookkeeping voucher use get_voucher.

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.

Read the templates that issue invoices on a schedule.

One API call. With template_id it answers with that one template, without it with a page of them.

A row is shorter than the record behind it: what a template will actually invoice, its lines and tax, is only in the record, so read by id to see that.

recurringTemplateSettings carries the schedule. executionStatus says whether it still runs, and finalize false means each run leaves a draft rather than issuing an invoice.

There is nothing to filter by, and reading is all the API allows.

Save a stored file, such as an uploaded receipt. One API call.

The bytes are not in this answer. Two ways to reach them:

• path — the file on the server's disk. Works if the client runs on that machine.

• uri — pass it to read_download to put the content in the conversation, or read it as a resource.

For a link a person can click, call get_deeplink with the voucher that lists this file. The web app has no page for the file itself.

Use download_document for a sales document, which is rendered rather than stored.

Save the rendered PDF of an invoice or another sales document.

One API call. Reports path and uri and keeps the bytes out of the answer, exactly as download_file does. For a link a person can click, call get_deeplink with the same id.

A draft has not been rendered and cannot be downloaded. An XRechnung is XML by nature and its PDF is only a preview. A ZUGFeRD document is a PDF with the XML inside it.

Put the contents of a downloaded file into this conversation.

No API call. Use it when the client cannot open the path or follow the uri, or when the content itself is the answer.

What arrives depends on the file: XML as text, so an XRechnung can be read. PDF as pictures of its pages, first 10 unless max_pages says otherwise — check pages against pagesShown and raise it, or pass null for up to 100, if the rest matters. Images as images. Anything else as an embedded binary.

Upload a receipt, which also creates a bookkeeping voucher for it.

Writes real accounting data, and the API cannot take it back: the answer carries a voucherId as well as a file id, and no call here deletes a voucher. Correcting one is a job for the web app. Confirm the organization with get_profile first. One API call, never retried.

Takes PDF, JPEG, PNG or XML, at most 5 MiB, from a path or a URL. An XML file is treated as an XRechnung. The voucher starts unchecked: update_voucher fills it in, and its finalize books it.

Attach a file to a voucher that already exists.

Use this rather than upload_file when the voucher is there: that one creates a new voucher for every file, and a voucher cannot be deleted through the API, so the wrong choice leaves one behind for good.

Writes to the account, and the API cannot take it back: there is no call that detaches a file. Confirm the organization with get_profile first. One API call, never retried.

Takes PDF, JPEG, PNG or XML, at most 5 MiB, from a path or a URL. The answer is the new file id, which download_file reads back.

Build a link that opens a record in the Lexware Office web app.

Costs no API call: the link is assembled from ids you already have. Use it whenever a person should look at something themselves, rather than describing where to click.

The link is not checked for existence, and a wrong id still produces one. Take the id from a search rather than from memory.

Read one of the lists this account is configured with.

One API call. Countries and posting categories run into the hundreds, so search is usually the difference between an answer and a wall of rows.

The answer reports total, what the account holds, and shown, what is in it. When those differ, narrow the search rather than raising limit.

A posting category id is what create_voucher books against, and type says whether a category takes money in or out.