Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

update_contact

DestructiveIdempotent

Modify an existing Lexware contact by sending only the fields you want changed. Supply the version from a prior read to prevent overwriting concurrent edits.

Instructions

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.

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": {
      "contact_id": "<contact_id>",
      "version": "<version>"
    },
    "name": "update_contact"
  }
}

Input Schema

Name	Required	Description
`name`	No	New company name, or for a person the last name.
`note`	No	Free-text note on the contact, at most 1000 characters.
`email`	No	One email address. On an update it replaces the ones the contact has rather than adding another.
`phone`	No	One phone number. As with the email address, this replaces rather than adds.
`roles`	No	Replaces the contact's roles. Leave unset to keep them. Passing only one role removes the other.
`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.
`contact_id`	Yes	The contact's Lexware id, as returned by search_contacts or referenced by a voucher.
`first_name`	No	New first name. Persons only.
`salutation`	No	New salutation. Persons only.
`tax_number`	No	National tax number. Companies only.
`billing_address`	No	The billing address. A contact has at most one.
`shipping_address`	No	The shipping address. A contact has at most one.
`vat_registration_id`	No	VAT registration id, for example 'DE123456789'. Companies only.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.4Nov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag readOnly=false, idempotent=true, destructive=true; the description adds value beyond them by disclosing the optimistic-concurrency contract, the exact failure mode ("nothing is written and the error says so"), the required prior read, and that real accounting data is written. That is precisely the behavioral information an agent cannot infer from the schema.

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 purpose and patch semantics, then the required read, then the conflict behavior. Every sentence carries operational information; nothing repeats the name or 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 13-parameter mutation with no output schema, the description covers the dangerous parts: preconditions, concurrency, and conflict handling. It is slightly thin on what a successful response contains (e.g. the new version to use for a subsequent update), which the missing output schema leaves unspecified.

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 exceeds it by explaining that unset fields are left untouched and by giving `version` a role (the value from the prior read) rather than just a type. It does not walk through individual fields, but the schema fully documents those.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Change an existing contact") and adds the crucial patch semantics ("Only the fields you give are changed"), which distinguishes it from create_contact and from a full replace. Sibling differentiation is implicit rather than explicit — it never names create_contact or update_voucher as contrasts — but the scope is unambiguous.

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 an explicit precondition ("Read the contact with `get_contact` first"), explains why (it carries the `version` this needs), notes the cost ("Two API calls"), and prescribes the recovery path when the version is stale. This is close to a complete when/how/and-if-it-fails guide.

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