Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

download_file

Read-only

Retrieve a stored Lexware file, such as an uploaded receipt, and return its disk path or URI so you can access the file bytes.

Instructions

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.

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": {
      "file_id": "<file_id>"
    },
    "name": "download_file"
  }
}

Input Schema

Name	Required	Description	Default
`file_id`	Yes	The file's Lexware id. A bookkeeping voucher lists the ids of its attachments in its `files` field.
`file_format`	No	Which representation to fetch. 'pdf' is what almost everything has. 'xml' only exists for an XRechnung, and asking for it otherwise is a not-found.	pdf

Output Schema

Name	Required	Description
`uri`	Yes	Resource URI for the same file. Read it to get the bytes, wherever the server runs.
`path`	Yes	Where the file was written on the server.
`size`	Yes	Size in bytes.
`mimeType`	Yes	The file's content type.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.3Nov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds the critical non-obvious contract that "The bytes are not in this answer," plus the environmental constraint that the `path` form only works if the client runs on the server machine. It also notes the "One API call" cost and the not-found behavior for XML when inappropriate, all beyond what the annotations provide.

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?

Front-loaded with the verb and resource, then a clean bulleted breakdown of the two access routes and the alternative tools; no sentence is filler. It runs somewhat longer than a two-parameter read tool strictly requires, but the density of distinct guidance keeps it close to earning every line.

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?

Given an output schema, read-only annotations, and full schema coverage, the description supplies exactly the gaps structured data cannot: that content is not returned inline, how to route to the bytes, and which siblings to prefer. Nothing an agent needs to call this correctly is missing.

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?

With 100% schema description coverage, the baseline is 3, and the description does not extend the parameters — `file_id` and `file_format` semantics (including the XML/XRechnung caveat) come entirely from the schema. The `path`/`uri` explanation concerns output fields rather than inputs, so it does not add parameter meaning here.

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?

States a specific verb and resource ("Save a stored file, such as an uploaded receipt") and explicitly distinguishes itself from the nearest sibling: "Use `download_document` for a sales document, which is rendered rather than stored." An agent can separate the two without opening either 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?

Gives explicit routing rules for every alternative: `path` when the client is co-located with the server, `uri` fed into `read_download` or read as a resource, and `get_deeplink` for a human-clickable link. It also states a negative — "The web app has no page for the file itself" — closing off a path an agent might otherwise try.

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