Skip to main content
Glama
Unofficial Lexware Office MCP Server

Unofficial Lexware Office MCP Server

read_download

Read-only

Loads a downloaded Lexware Office file into the conversation when the client cannot open its path or URI, returning XML as text and PDF pages or images for direct review.

Instructions

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.

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": {
      "uri": "<uri>"
    },
    "name": "read_download"
  }
}

Input Schema

NameRequiredDescriptionDefault
uriYesThe `uri` a download reported, of the form lexware://download/... Only files this server downloaded can be read.
max_pagesNoFor a PDF, how many pages to render from the front. Defaults to 10. Pass null for every page, up to 100, and expect roughly two thousand tokens per page.

Output Schema

NameRequiredDescriptionDefault
uriYesThe download that was read.
sizeYesSize in bytes.
pagesNoHow many pages the document has, for a PDF.
mimeTypeYesThe file's content type.
pagesShownNoHow many of them were rendered into this answer.
deliveredAsYesHow the content was put into the answer: 'text' for something readable such as an XRechnung, 'image' for a picture, 'pages' for a PDF rendered to images, or 'binary' for anything the client has to handle itself.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.3

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations by describing format-dependent behavior: XML arrives as text, PDF arrives as page images capped at 10, images as images, everything else as embedded binary. It also explains how to detect truncation (compare `pages` to `pagesShown`) and how to request more, which is exactly the operational context annotations cannot supply.

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?

The instruction and the when-to-use condition are front-loaded, then the format behavior follows in a scannable list. Slightly heavy formatting and a few appositive asides, but no sentence is filler.

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?

For a read-only two-parameter tool, the description covers what it does, when to prefer it, what each format returns, and how to handle pagination limits. An output schema exists, yet the format-dependent return explanation is still valuable and no decision-relevant gap remains.

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, but the description adds practical meaning: `max_pages` controls PDF rendering from the front, null means all pages up to 100, and the `uri` must be a lexware://download/... value the server itself produced. The output-comparison advice adds usage semantics the schema does not carry.

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 concrete action on a concrete resource: put the contents of a downloaded file into the conversation. It distinguishes itself from the download siblings by clarifying that it makes no API call and operates on files this server already fetched, which lets an agent separate it from download_file and download_document.

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?

Gives an explicit trigger: use it when the client cannot open the `path` or follow the `uri`, or when the content itself is the answer. It also implicitly contrasts with the download tools by noting no API call is made, though it does not name the sibling alternatives directly.

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