Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

get_deeplink

Read-only

Build a direct Lexware Office web app link from a record type and ID so users can open invoices, contacts, vouchers, and other records themselves without an API call.

Instructions

Build a link that opens a record in the Lexware Office web app.

Costs no API call: the link is assembled from ids you already have. Use it whenever a person should look at something themselves, rather than describing where to click.

The link is not checked for existence, and a wrong id still produces one. Take the id from a search rather than from memory.

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": {
      "target": "<target>",
      "target_id": "<target_id>"
    },
    "name": "get_deeplink"
  }
}

Input Schema

Name	Required	Description	Default
`action`	No	Whether to open the record or open it for editing. A contact has a single page and always opens on it.	view
`target`	Yes	What the link should point at.
`target_id`	Yes	The Lexware id of a record of that exact type. A file id is not the id of the voucher it hangs on, and the mismatch still builds a link — one that leads nowhere.

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 already declare readOnlyHint=true and openWorldHint=false, and the description adds non-obvious behavior on top: the call costs no API quota, the generated link is not validated for existence, and a wrong id still yields a (dead) link. That last point is a real failure mode an agent would otherwise not anticipate, and it is not derivable from the schema or annotations.

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?

Four short sentences, front-loaded with the highest-value fact (no API cost) and then the caveat about unchecked ids. Every sentence carries information an agent needs; nothing is redundant with the name or 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 three-parameter, no-output-schema utility this is nearly complete: purpose, cost model, prerequisite sourcing of ids, and the silent-failure caveat are all covered. The only omission is any statement of the return shape (presumably a URL string), which is strongly implied by 'Build a link' but never said outright.

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 both enum parameters carry their own descriptions, so the baseline is 3. The description adds meaning beyond the schema by explaining that target_id must be the Lexware id of the exact record type and that a mismatched id (e.g. a file id vs. its voucher) silently produces a broken link — a semantic constraint the schema only hints at.

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: 'Build a link that opens a record in the Lexware Office web app.' The follow-up sentence ('the link is assembled from ids you already have') makes clear this is a pure URL-construction utility, which cleanly separates it from every sibling (search_*, get_*, create_*, download_*).

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 usage condition: 'Use it whenever a person should look at something themselves, rather than describing where to click,' which is exactly the decision point against plain get_* tools. It also adds a prerequisite ('Take the id from a search rather than from memory'), implicitly routing through search_contacts/search_vouchers. It stops short of naming a specific sibling or stating when-not to use it, so a 4 rather than a 5.

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