Skip to main content
Glama
Sign In
Unofficial Lexware Office MCP Server

Unofficial Lexware Office MCP Server

by benethos-hub
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_master_data

Read-only

Read an account's configured lists such as countries, payment conditions, posting categories, and print layouts. Use search to narrow hundreds of rows and find the IDs other actions need.

Instructions

Read one of the lists this account is configured with.

One API call. Countries and posting categories run into the hundreds, so search is usually the difference between an answer and a wall of rows.

The answer reports total, what the account holds, and shown, what is in it. When those differ, narrow the search rather than raising limit.

A posting category id is what create_voucher books against, and type says whether a category takes money in or out.

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": {
      "kind": "<kind>"
    },
    "name": "get_master_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesWhich list to read. 'posting-categories' holds the categories a bookkeeping voucher books against, 'countries' the codes an address takes.
limitNoHow many rows to put in the answer.
searchNoNarrow the list. Matched case-insensitively against every text a row carries, so 'income' keeps the categories of that type and 'Erloese' those named so.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.3

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds real behavioral context beyond that — a single API call per invocation, an explicit statement of the returned total/shown counters, and the rule that search is preferred over a higher limit. Return shape is described despite there being no output schema. It does not mention per-kind limits (e.g. the 250 cap behavior) or whether results are ordered, which keeps it from a 5.

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?

Five short sentences, front-loaded with what the tool reads, then why search matters, then the return shape, then the downstream id meaning. Every line carries information — nothing restates the tool 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 3-parameter read-only tool with no output schema, the description covers purpose, search strategy, return semantics (total vs shown), and downstream usage of the ids. The only gap is that two enum kinds ('payment-conditions', 'print-layouts') are never characterized in the description, leaving the agent to infer their content.

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 would be 3, but the description adds meaning the schema does not: `search` behavior is illustrated with a concrete case ('income' keeps categories of that type, 'Erloese' those named so), and the `limit` vs `search` trade-off is spelled out. The semantic payload of a posting-category id and its `type` in/out meaning is also supplied.

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 ('Read') and resource ('one of the lists this account is configured with'), and the enum in the schema pins down exactly which lists. It is clearly a master/reference-data reader, distinguishable from the entity getters like get_contact and get_article, though the phrase 'lists this account is configured with' is slightly abstract until the schema is opened.

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 concrete operative guidance: use `search` because countries and posting categories number in the hundreds, and when `total` exceeds `shown`, narrow the search rather than raising `limit`. It also tells the agent that posting category ids are what `create_voucher` books against, linking it to a sibling. It stops short of stating when to use this instead of other list/search tools, but the when-to-use context is clear.

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

Deploy Server

Other Tools