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

Unofficial Lexware Office MCP Server

by benethos-hub
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_vouchers

Read-only

Search invoices, credit notes, quotations, and bookkeeping vouchers to get their IDs for use with other tools. Filter by type, status, date, or contact to narrow results.

Instructions

Find invoices, credit notes, quotations and bookkeeping vouchers.

One API call per page. The only way to turn a question about the books into the ids get_voucher, get_payments and the document tools need. Starting from a customer name, get the contact id from search_contacts first and pass it here.

Rows carry id, type, status, number, dates, contact name, total and open amount. A row marked archived is filed away.

Narrow voucher_type and voucher_status to keep the answer small. voucher_status 'open' or 'overdue' answers "what is still outstanding" without paging through everything.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_vouchers"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoZero-based page number. Read the `page` block of the previous result before asking for another one, rather than paging blindly.
sizeNoRows per page. A larger page costs the same single API call but more of the answer's token budget, so raise it only when the whole list is genuinely needed.
sortNoOrdering. Newest voucher date first by default. createdDate and updatedDate are when it was entered or last changed.voucherDate,DESC
date_toNoLatest voucher date, as YYYY-MM-DD.
archivedNoSet true to look at archived documents, false for active ones. Left unset, both are returned.
date_fromNoEarliest voucher date, as YYYY-MM-DD. This is the date on the document, not the date it was entered.
contact_idNoOnly documents for this contact, by id from search_contacts.
voucher_typeNoWhich kind of document to look for. 'any' covers all of them. 'invoice' means a sales document, 'salesinvoice' and 'purchaseinvoice' are the bookkeeping records. Dunnings cannot be found here at all.any
voucher_numberNoThe document number, for example 'RE0001', matched in full and ignoring case. Not a prefix.
voucher_statusNoWhich state to look for. 'any' covers all of them. 'open' is everything unpaid, overdue included, 'overdue' only what is past its due date. 'paid' is settled, 'draft' is not finalized, 'voided' is cancelled.any

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.3

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real context beyond that: one API call per page, the exact row fields returned, the meaning of an 'archived' row, and the exclusion that dunnings cannot be found here at all. It stops short of describing pagination termination or result ordering behavior beyond the sort default, 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the id-producing role, then usage, then return shape, then filtering advice — a sensible order with no filler sentences. The line-broken formatting is slightly choppy but each sentence carries information.

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 10-parameter read-only search with no output schema, the description covers what the tool does, how to chain into it, what rows contain, and how to keep results small. Nothing an agent needs to call it 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%, so the baseline is 3, but the description adds genuine meaning on top: it explains why to narrow voucher_type and voucher_status, and clarifies that 'open' includes overdue while 'overdue' is only past due date. That disambiguates an enum distinction the schema alone leaves implicit.

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 set ('Find invoices, credit notes, quotations and bookkeeping vouchers') and explicitly positions itself as the id-producing step that feeds get_voucher, get_payments and the document tools. An agent can distinguish it from get_voucher and search_contacts without opening any 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: start from a customer name, resolve the contact id via search_contacts first, then pass it here. It also names the when-to-use shortcut for outstanding balances ('voucher_status' 'open' or 'overdue') and tells the agent to narrow voucher_type/voucher_status to keep answers small.

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