Skip to main content
Glama
Unofficial Lexware Office MCP Server

Unofficial Lexware Office MCP Server

attach_file_to_voucher

Attach a PDF, JPEG, PNG, or XML file to an existing voucher instead of creating a new one, preventing undeletable duplicate vouchers. Confirm the organization before writing.

Instructions

Attach a file to a voucher that already exists.

Use this rather than upload_file when the voucher is there: that one creates a new voucher for every file, and a voucher cannot be deleted through the API, so the wrong choice leaves one behind for good.

Writes to the account, and the API cannot take it back: there is no call that detaches a file. Confirm the organization with get_profile first. One API call, never retried.

Takes PDF, JPEG, PNG or XML, at most 5 MiB, from a path or a URL. The answer is the new file id, which download_file reads back.

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": {
      "voucher_id": "<voucher_id>",
      "source": "<source>"
    },
    "name": "attach_file_to_voucher"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceYesThe file: a path on this machine, or a URL to fetch it from. A URL works only for addresses the account owner allowed.
voucher_idYesThe voucher to hang the file on, by id from search_vouchers. It has to exist already.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.4

TDQS

A4.8/5.0
Behavior5/5

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

The annotations only say this is a non-read-only, non-idempotent, non-destructive write; the description adds the materially important traits: the effect is irreversible because no detach call exists, the account must be confirmed first, and the call is never retried. It also discloses accepted formats, the 5 MiB ceiling, and the return value. The irreversibility note sits in mild tension with destructiveHint=false but does not contradict it, since attaching is additive rather than destructive.

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 paragraphs, front-loaded with the core action and the sibling distinction, and every sentence carries operational information. The em-dash asides and bold emphasis make it slightly denser than necessary for a two-parameter tool.

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?

No output schema exists, and the description covers the return value (the new file id, readable via `download_file`), the irreversible side effect, prerequisites, input limits, and failure avoidance. Nothing an agent needs in order 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.

Parameters4/5

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

Schema coverage is 100% and the schema already explains `source` (path or URL) and `voucher_id` (must already exist). The description still earns credit by adding constraints absent from the schema: the allowed formats (PDF, JPEG, PNG, XML) and the 5 MiB size limit.

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?

Opens with a specific verb+resource ("Attach a file to a voucher that already exists") and immediately contrasts with the sibling `upload_file`, which creates a new voucher. An agent can distinguish 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?

Explicit routing rule: use this when the voucher exists, use `upload_file` when it does not, with the consequence of choosing wrong spelled out (an undeletable voucher). It also states the pre-flight step (`get_profile`) and the downstream consumer (`download_file`), so both when-to-use and the surrounding call sequence are covered.

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