Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

create_article

Add a new product or service article to the Lexware Office catalogue. Returns the new article ID and version for later retrieval.

Instructions

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.

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": {
      "title": "<title>",
      "article_type": "<article_type>",
      "unit_name": "<unit_name>",
      "price": "<price>",
      "tax_rate": "<tax_rate>"
    },
    "name": "create_article"
  }
}

Input Schema

Name	Required	Description	Default
`gtin`	No	Barcode number. Thirteen digits, checked by the API.
`note`	No	Internal note. Not shown on a document.
`price`	Yes	The price for one unit.
`title`	Yes	What the article is called on a document.
`tax_rate`	Yes	The tax rate as a percentage, for example 19.
`unit_name`	Yes	What one of it is, for example 'Stueck' or 'Stunde'.
`description`	No	Longer text shown under the title on a document.
`article_type`	Yes	Whether this is goods or a service.
`leading_price`	No	Whether `price` is before or after tax. The other figure is computed by the API from `tax_rate`.	NET
`article_number`	No	Your own number for it. Not assigned by Lexware.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.4Nov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only give the readOnly/idempotent/destructive triad, yet the description adds high-value traits: it writes to the account, is a single non-retried API call, and returns only id and version rather than the record. The non-retry and partial-return facts are exactly the kind of behavior an agent cannot infer from 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?

Short, front-loaded, and every line carries information about behavior or next steps. The hard line breaks make it slightly choppy but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description fills the gap by stating exactly what is returned (id and version, not the record) and why read-back is needed. For a 10-parameter write tool it leaves no essential calling detail unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter is already documented, so the schema does the heavy lifting. The description reinforces that price is derived from the given figure via tax_rate, but adds no field-level detail beyond that, matching the baseline of 3.

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?

"Add an article to the catalogue" gives a specific verb and resource, and the description explicitly contrasts it with a voucher and names delete_article and get_article, so an agent can place it among siblings without reading schemas.

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?

It states the read-back path (use get_article to see the computed price) and notes articles can be removed with delete_article, which is clear routing context. It doesn't explicitly exclude update_article for modifying existing articles, so it stops short of full when/when-not coverage.

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