Unofficial Lexware Office MCP Server

Overview Schema Source Related Servers Discussions Admin

get_recurring_templates

Read-only

Read recurring invoice templates to inspect their schedules, execution status, and draft finalization behavior, or fetch a single template by ID for full line and tax details.

Instructions

Read the templates that issue invoices on a schedule.

One API call. With template_id it answers with that one template, without it with a page of them.

A row is shorter than the record behind it: what a template will actually invoice, its lines and tax, is only in the record, so read by id to see that.

recurringTemplateSettings carries the schedule. executionStatus says whether it still runs, and finalize false means each run leaves a draft rather than issuing an invoice.

There is nothing to filter by, and reading is all the API allows.

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": "get_recurring_templates"
  }
}

Input Schema

Name	Required	Description
`page`	No	Zero-based page number. Read the `page` block of the previous result before asking for another one, rather than paging blindly.
`size`	No	Rows 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.
`sort`	No	Which date to order by, newest first unless ',ASC' is added. The API sorts on these four and nothing else.
`template_id`	No	Read one template by id. Left unset, a page of them comes back instead.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.3Nov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

readOnlyHint already covers the safety profile, and the description still adds substantive behavior: one API call per request, a list row being a truncated projection of the full record, and the meaning of key response fields (`recurringTemplateSettings` for schedule, `executionStatus` for liveness, `finalize` false meaning drafts instead of issued invoices). That is exactly the context annotations cannot convey.

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 single most important fact (list vs by-id) and free of filler. The phrasing is slightly oblique in places ('a row is shorter than the record behind it'), costing a moment of parsing, but every sentence carries information.

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?

With no output schema, the description takes on the return-value burden and mostly discharges it: it describes the two result shapes and the three response fields an agent must interpret. Pagination mechanics are deferred to the `page`/`size` schema descriptions, which is a reasonable split for a four-parameter read tool.

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; the description earns above that by explaining why `template_id` matters (the list row omits invoice lines and tax) rather than merely restating that it selects one record. Page/size/sort are left entirely to their already-detailed schema descriptions.

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 ('Read the templates that issue invoices on a schedule') and immediately splits the two modes: with `template_id` one template, without it a page. No sibling tool covers recurring templates, so no disambiguation burden exists and the definition stands on its own.

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 explicit routing guidance between the two modes ('read by id to see' the lines and tax) and rules out a whole class of usage with 'There is nothing to filter by.' It also sets the boundary of the API ('reading is all the API allows'), though it does not relate this tool to adjacent read tools like get_sales_document.

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