Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

update_article

DestructiveIdempotent

Updates only the supplied fields on an existing article and uses a version check to block overwrites when the record changed since last read.

Instructions

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.

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": {
      "article_id": "<article_id>",
      "version": "<version>"
    },
    "name": "update_article"
  }
}

Input Schema

Name	Required	Description
`gtin`	No	New barcode number.
`note`	No	New internal note.
`price`	No	New price for one unit.
`title`	No	New title.
`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.
`tax_rate`	No	New tax rate as a percentage.
`unit_name`	No	New unit.
`article_id`	Yes	The article's Lexware id, as returned by search_articles.
`description`	No	New description.
`article_type`	No	Change goods to service or back.
`leading_price`	No	Whether the new price is before or after tax. Left unset, the side the article already used is kept.
`article_number`	No	New article number.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.4Nov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint and idempotentHint, but the description adds real value: it confirms the update is a partial patch, discloses optimistic-concurrency behavior with a 'nothing is written' failure mode, and warns that supplying `price` replaces one side while the other is recomputed by the API. It stops short of covering reversibility or permissions, so not a 5.

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?

Short, front-loaded, and every sentence carries non-obvious information: partial semantics, the read-before-write requirement, the concurrency failure mode, and the price/leading_price rule. No redundant restatement of the schema.

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 12-parameter mutation with no output schema, the description covers the risky parts an agent must know: concurrency, partiality, and price recomputation. It does not say what the call returns or mention any permission requirements, which keeps it just under complete.

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, and the description earns above baseline by explaining the cross-field interaction between `price` and `leading_price` (including that the non-leading side is recomputed), which the schema entries do not state. Other parameters such as `article_id` and `version` are left entirely to the schema.

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?

The first two sentences state a specific verb (change) and resource (article) and immediately pin down the partial-update semantics: only supplied fields are modified. That distinguishes it from create_article and delete_article without the agent needing to open 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 Guidelines5/5

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

It names the prerequisite call explicitly (read with `get_article` first), explains why (to obtain `version` and see current values), and quantifies the cost as two API calls. It also discloses the failure condition (record changed since the read) rather than leaving the agent to discover it.

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