What can you do with this server?

The lexware-mcp-server connects to the Lexware Office API, providing 67 tools across 20 resource domains to manage business operations: Sales Documents * Invoices, Credit Notes, Quotations, Order Confirmations, Delivery Notes: Create, retrieve, download PDF, pursue from a preceding sales voucher, and get deep links * Down Payment Invoices: Retrieve, download PDF, and get deep links * Dunnings: Create, retrieve, download PDF, pursue from an invoice, and get deep links * Voucherlist: Search and filter across all voucher types (invoices, credit notes, quotations, order confirmations, delivery notes, down payment invoices, dunnings, purchase invoices/credit notes) by date, status, and contact Contacts & Articles * Contacts: List (filter by name, email, number, vendor/customer/archived status), retrieve, create, update, and get deep links * Articles: List (filter by GTIN, type, article number), retrieve, create, update, and delete Bookkeeping * Vouchers: List, retrieve, create, update, and upload file attachments * Payments: Retrieve payment details for a specific voucher Reference Data * List countries, payment conditions, posting categories, and print layouts * Retrieve organization profile information System & Automation * Webhooks: Create, list, retrieve, and delete event subscriptions; verify webhook signatures (RSA-SHA512) * Files: Upload, download, and check processing status * Recurring Templates: List and retrieve recurring invoice templates The server also offers six entry points (split servers: sales, contacts, bookkeeping, reference, system, all) to control tool count and context size.

How do I use lexware-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lexware-mcp-server Create an invoice for ACME Corp for 150 EUR" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ko zh

lexware-mcp-server

by lazyants

Overview Schema Related Servers Score Discussions

TypeScript

Remote

lexware-mcp-server

Tests

MCP server for the Lexware Office API. Manage invoices, contacts, articles, vouchers, and more through the Model Context Protocol.

Unofficial — community project. Not affiliated with, endorsed by, or supported by Lexware GmbH or Haufe Group. "Lexware" and "Lexware Office" are trademarks of their respective owners; used here only to identify the API this client targets (nominative fair use).

66 tools across 20 resource domains, with 6 entry points so you can pick the right server for your MCP client's tool limit.

Installation

npm install -g @lazyants/lexware-mcp-server

Or run directly:

npx @lazyants/lexware-mcp-server

Related MCP server: Lexware Office MCP Server

Configuration

The API token is resolved in this order:

OS keyring (recommended — token never written to disk in plain text)
Environment variable LEXWARE_API_TOKEN

Store the token in the OS keyring

Get your token from the Lexware Office API settings, then store it with the native credential manager for your OS.

IMPORTANT

The commands below read the token from an interactive prompt rather than taking it as an argument, so it never lands in your shell history or the process list. Avoid pasting the token directly onto the command line.

macOS

Omitting the value after -w makes security prompt for the token (with confirmation):

security add-generic-password -s "lexware-mcp" -a "api-token" -w

Windows (PowerShell)

cmdkey can only take the token as a command-line argument, which exposes it in the process list. Instead, read it from a hidden prompt and write it straight into Windows Credential Manager via CredWrite, so the token never reaches argv. The credential's target name is <account>.<service> — api-token.lexware-mcp for the default service — which is exactly what the server reads back:

$secure = Read-Host -AsSecureString "Lexware API token"
Add-Type -Namespace LexwareKeyring -Name Native -MemberDefinition @'
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct CREDENTIAL {
    public uint Flags;
    public uint Type;
    [MarshalAs(UnmanagedType.LPWStr)] public string TargetName;
    [MarshalAs(UnmanagedType.LPWStr)] public string Comment;
    public System.Runtime.InteropServices.ComTypes.FILETIME LastWritten;
    public uint CredentialBlobSize;
    public IntPtr CredentialBlob;
    public uint Persist;
    public uint AttributeCount;
    public IntPtr Attributes;
    [MarshalAs(UnmanagedType.LPWStr)] public string TargetAlias;
    [MarshalAs(UnmanagedType.LPWStr)] public string UserName;
}
[DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern bool CredWriteW(ref CREDENTIAL credential, uint flags);
'@
$blob = [Runtime.InteropServices.Marshal]::SecureStringToCoTaskMemUnicode($secure)
try {
    $cred = New-Object LexwareKeyring.Native+CREDENTIAL
    $cred.Type = 1                              # CRED_TYPE_GENERIC
    $cred.Persist = 2                           # CRED_PERSIST_LOCAL_MACHINE
    $cred.TargetName = 'api-token.lexware-mcp'  # "<account>.<service>"
    $cred.UserName = 'api-token'
    $cred.CredentialBlob = $blob
    $cred.CredentialBlobSize = $secure.Length * 2   # UTF-16 bytes, no terminator
    if (-not [LexwareKeyring.Native]::CredWriteW([ref]$cred, 0)) {
        throw "CredWrite failed (Win32 error $([Runtime.InteropServices.Marshal]::GetLastWin32Error()))"
    }
    Write-Host 'Stored Lexware API token in Windows Credential Manager.'
} finally {
    [Runtime.InteropServices.Marshal]::ZeroFreeCoTaskMemUnicode($blob)
    $secure.Dispose()
    Remove-Variable secure, blob
}

Using a custom LEXWARE_KEYRING_SERVICE (e.g. acme)? Set TargetName to api-token.acme to match — the server looks the token up under <account>.<service>.

Linux

secret-tool store --label="Lexware Office API" service lexware-mcp username api-token
# (prompts for the token value)

Once stored, MCP config files need no credentials at all — the server reads the token from the keyring at startup.

Use an environment variable instead

If you prefer not to use the keyring, set LEXWARE_API_TOKEN in your shell or MCP client config:

export LEXWARE_API_TOKEN=your-token-here

Environment variables

Variable	Default	Description
`LEXWARE_API_TOKEN`	—	API token; used when the keyring has no entry for the configured service
`LEXWARE_KEYRING_SERVICE`	`lexware-mcp`	Keyring service name. Override when connecting to multiple Lexware accounts simultaneously — run one server instance per account, each with its own service name

Optionally override the webhook-signature public key used by lexware_verify_webhook_signature (by default fetched from Lexware and cached):

export LEXWARE_WEBHOOK_PUBLIC_KEY="$(cat lexware-webhook-public.pem)"

Entry Points

Command	Domains	Tools
`lexware-mcp-server`	All 20 domains	66
`lexware-mcp-sales`	Invoices, Credit Notes, Quotations, Order Confirmations, Delivery Notes, Down Payment Invoices, Dunnings, Voucherlist	32
`lexware-mcp-contacts`	Contacts, Articles	10
`lexware-mcp-bookkeeping`	Vouchers, Voucherlist, Payments	8
`lexware-mcp-reference`	Countries, Payment Conditions, Posting Categories, Profile, Print Layouts	5
`lexware-mcp-system`	Event Subscriptions, Files, Recurring Templates	12

Use split servers to reduce context size — pick only the splits you need.

Claude Code

Add to ~/.claude/settings.json. If you stored the token in the OS keyring under the default service name lexware-mcp (recommended), no env key is needed:

{
  "mcpServers": {
    "lexware": {
      "command": "npx",
      "args": ["-y", "@lazyants/lexware-mcp-server"]
    }
  }
}

If you prefer the environment variable approach:

{
  "mcpServers": {
    "lexware": {
      "command": "npx",
      "args": ["-y", "@lazyants/lexware-mcp-server"],
      "env": { "LEXWARE_API_TOKEN": "your-token-here" }
    }
  }
}

Split servers

Use split servers to reduce context size — pick only the entry points you need. The -p @lazyants/lexware-mcp-server flag tells npx which package to source the command from; the final argument (e.g. lexware-mcp-sales) is the specific entry-point binary defined in that package (see Entry Points):

{
  "mcpServers": {
    "lexware-sales": {
      "command": "npx",
      "args": ["-y", "-p", "@lazyants/lexware-mcp-server", "lexware-mcp-sales"]
    },
    "lexware-contacts": {
      "command": "npx",
      "args": ["-y", "-p", "@lazyants/lexware-mcp-server", "lexware-mcp-contacts"]
    }
  }
}

Multi-account example (two Lexware companies, tokens stored under separate keyring service names):

{
  "mcpServers": {
    "lexware-company-a": {
      "command": "npx",
      "args": ["-y", "@lazyants/lexware-mcp-server"],
      "env": { "LEXWARE_KEYRING_SERVICE": "lexware-company-a" }
    },
    "lexware-company-b": {
      "command": "npx",
      "args": ["-y", "@lazyants/lexware-mcp-server"],
      "env": { "LEXWARE_KEYRING_SERVICE": "lexware-company-b" }
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json. With the OS keyring (recommended — assumes the token is stored under the default service name lexware-mcp):

{
  "mcpServers": {
    "lexware": {
      "command": "npx",
      "args": ["-y", "@lazyants/lexware-mcp-server"]
    }
  }
}

With an environment variable instead:

{
  "mcpServers": {
    "lexware": {
      "command": "npx",
      "args": ["-y", "@lazyants/lexware-mcp-server"],
      "env": { "LEXWARE_API_TOKEN": "your-token-here" }
    }
  }
}

Tools

Invoices (5 tools) — sales

lexware_create_invoice (supports finalize=true at creation), lexware_get_invoice, lexware_download_invoice_file, lexware_pursue_invoice, lexware_deeplink_invoice

Credit Notes (5 tools) — sales

lexware_create_credit_note, lexware_get_credit_note, lexware_download_credit_note_file, lexware_pursue_credit_note, lexware_deeplink_credit_note

Quotations (4 tools) — sales

lexware_create_quotation, lexware_get_quotation, lexware_download_quotation_file, lexware_deeplink_quotation

Order Confirmations (5 tools) — sales

lexware_create_order_confirmation, lexware_get_order_confirmation, lexware_download_order_confirmation_file, lexware_pursue_order_confirmation, lexware_deeplink_order_confirmation

Delivery Notes (5 tools) — sales

lexware_create_delivery_note, lexware_get_delivery_note, lexware_download_delivery_note_file, lexware_pursue_delivery_note, lexware_deeplink_delivery_note

Down Payment Invoices (3 tools) — sales

lexware_get_down_payment_invoice, lexware_download_down_payment_invoice_file, lexware_deeplink_down_payment_invoice

Dunnings (4 tools) — sales

lexware_get_dunning, lexware_download_dunning_file, lexware_pursue_dunning, lexware_deeplink_dunning

Voucherlist (1 tool) — sales, bookkeeping

lexware_list_voucherlist

By default this is a single-page passthrough of the API response. Two additions are opt-in:

fetchAllPages: true follows pagination until every page is retrieved, capped at 100 requests. The result adds fetchedPages and truncated, the latter marking a set cut short by the cap — API fields such as totalElements are preserved.
contactName (SQL-style %/_ wildcards, case-insensitive) and hasOpenAmount filter client-side after fetching, and each implies fetchAllPages. They are applied here rather than on lexware_list_vouchers because /voucherlist is the response shape that carries contactName and openAmount.

page cannot be combined with any of the three — those modes read every page, so a start offset is meaningless. Use size to control the batch size instead. The combination is rejected rather than silently ignored, so nobody can believe an offset was honored when it was not.

Contacts (5 tools) — contacts

lexware_list_contacts, lexware_get_contact, lexware_create_contact, lexware_update_contact, lexware_deeplink_contact

Articles (5 tools) — contacts

lexware_list_articles, lexware_get_article, lexware_create_article, lexware_update_article, lexware_delete_article

Vouchers (6 tools) — bookkeeping

lexware_list_vouchers, lexware_get_voucher, lexware_create_voucher, lexware_update_voucher, lexware_upload_voucher_file, lexware_deeplink_voucher

lexware_list_vouchers requires voucherNumber. GET /vouchers is a lookup endpoint, not a browsable collection — the API answers 400 "voucherNumber parameter is required" without it. To browse or filter vouchers, use lexware_list_voucherlist, which is the collection endpoint and also carries the summary fields (contactName, openAmount) that /vouchers does not.

lexware_get_voucher normalizes voucherStatus to lowercase and retries a 404 three times (1 s / 2 s / 4 s) to cover the indexing delay after an upload; if the voucher is still missing it returns { voucherId, status: "processing", message }. Other failures are reported as errors.

Payments (1 tool) — bookkeeping

lexware_get_payments

Countries (1 tool) — reference

lexware_list_countries

Payment Conditions (1 tool) — reference

lexware_list_payment_conditions

Posting Categories (1 tool) — reference

lexware_list_posting_categories

Profile (1 tool) — reference

lexware_get_profile

Print Layouts (1 tool) — reference

lexware_list_print_layouts

Event Subscriptions (5 tools) — system

lexware_create_event_subscription, lexware_list_event_subscriptions, lexware_get_event_subscription, lexware_delete_event_subscription, lexware_verify_webhook_signature

Files (4 tools) — system

lexware_upload_file, lexware_download_file, lexware_get_file_status, lexware_deeplink_file

lexware_get_file_status calls GET /files/{id}/status. The bare GET /files/{id} is the binary download route — with Accept: application/json it still answers 200 with the file body base64-encoded, so it can never yield status metadata. The status route is scope-gated: API keys without the necessary permission get access_denied from Lexware rather than a status.

Both upload tools (lexware_upload_file and lexware_upload_voucher_file) take the file either as contentBase64 or as filePath — an absolute path readable by the MCP server process. Prefer filePath for anything sizeable: base64 inflates the payload by about a third and has to travel through the model's context window. With filePath, fileName defaults to the file's base name and contentType is auto-detected for .png, .jpg/.jpeg, .tiff/.tif and .xml, falling back to application/pdf. Provide exactly one of the two — supplying both, or neither, is a validation error.

Uploads are capped at 5 MB. For filePath the size is taken from the opened descriptor before the file is read, so an oversized file costs a stat rather than a full load into memory, and anything that is not a regular file is refused outright (reading /dev/zero would otherwise never return). The decoded byte count is checked again afterwards, which also covers contentBase64. Failures carry a file_too_large error with the actual and maximum sizes.

Recurring Templates (3 tools) — system

lexware_list_recurring_templates, lexware_get_recurring_template, lexware_deeplink_recurring_template

Security

Use the OS keyring to keep your API token out of config files and shell history entirely (see Configuration)
Never commit your API token to version control
Use read-only access when you only need to list/get resources
Create, update, and delete tools modify real business data — invoices, contacts, and accounting records in your Lexware account
Rate limiting is handled automatically: requests retry with exponential backoff on 429, including file uploads — the multipart body is rebuilt fresh on every retry attempt, so it can be replayed safely

Releasing

Releases ship via the GitHub Release event. Maintainer flow:

Bump the version in package.json, package-lock.json, and server.json (npm version <x.y.z> --no-git-tag-version updates the first two together). npm run check-versions hard-fails unless package.json#/version, server.json#/packages[0].version, and both package-lock.json version fields (root and packages[""]) all agree. server.json#/version is checked more loosely: it must be present, but it is only compared against packages[0].version as a regression check — it may legitimately be ahead (registry-only republishes bump just that field), so a value left behind at the previous release passes with a WARN: line and no failure. For an ordinary release both should move together, so read the script's output rather than trusting its exit code. CHANGELOG.md is not checked at all.
Update CHANGELOG.md.
Commit, and merge the version bump to main before creating the release. Then create the tag yourself, on a SHA you have checked, and only then create the release from it:
```
V=X.Y.Z && PR=<release-pr-number> &&
  SHA="$(gh pr view "$PR" --json mergeCommit -q .mergeCommit.oid)" && test -n "$SHA" &&
  git fetch origin main && git merge-base --is-ancestor "$SHA" origin/main &&
  PKG="$(git show "$SHA:package.json")" &&
  test "$(printf '%s' "$PKG" | node -pe 'JSON.parse(require("fs").readFileSync(0,"utf8")).version')" = "$V" &&
  CL="$(git show "$SHA:CHANGELOG.md")" &&
  printf '%s\n' "$CL" | awk -v v="$V" 'index($0,"## ["v"]")==1{f=1;next} /^## \[/{f=0} /^\[[0-9]+\.[0-9]+\.[0-9]+\]:/{f=0} f' > "/tmp/notes-v$V.md" &&
  grep -q '[^[:space:]]' "/tmp/notes-v$V.md" &&
  git tag -a "v$V" "$SHA" -m "v$V" &&
  git push origin "v$V" &&
  gh release create "v$V" --verify-tag --notes-file "/tmp/notes-v$V.md"
```
The failure this prevents: with no existing tag, gh release create places one on the tip of the default branch, so running it while the bump is still on a release branch tags the previous release's commit. The workflow then publishes whatever version it finds in that commit's package.json, and you get a vX.Y.Z GitHub Release that silently republishes the old version. Since 5.2.0 the publish workflow itself refuses to continue when GITHUB_REF_NAME is not v<package.json version> (#103), so a mis-tagged release now fails before npm publish rather than silently republishing. That guard fires only once the workflow is already running, though — the sequence above is what stops the wrong commit being tagged in the first place, so keep using it rather than relying on the workflow to catch the mistake.
Each element is load-bearing:
- gh pr view … .mergeCommit.oid names the release PR's own squash commit. Do not substitute git rev-parse origin/main — that is merely whatever is on main at the moment you look, so an unrelated merge landing in the gap gets tagged and shipped instead. gh exits 0 and prints nothing for an unmerged PR, hence the explicit test -n.
- The && chain stops on the first failure instead of falling through to the irreversible step. Both git show calls are assigned to a variable rather than piped directly, so their exit status is actually checked — a pipeline reports only its last command's status unless pipefail is set, which is not assumed here.
- git merge-base --is-ancestor proves the commit is actually reachable from main. Mere existence is not enough — a commit can be present locally because some other branch was fetched, and if its version files happen to match it would otherwise sail through every remaining check.
- The version test reads package.json out of the target commit, not the working tree, which would still show the right version while $SHA pointed elsewhere.
- The awk lifts that version's section out of the commit's CHANGELOG.md for --notes-file. Without it the release body is whatever --notes-from-tag finds in the annotation — for this flow, the literal string vX.Y.Z, which is a poor release note for any version and an actively misleading one for a major carrying a breaking change. It stops at the next ## [ heading or at the first link-reference definition, because the oldest entry in the file has no heading after it and would otherwise swallow the entire link-reference block. grep -q rather than test -s guards the result: a section that is empty apart from its blank line still produces a one-byte file, which test -s accepts.
- --verify-tag makes gh abort rather than invent a tag if the push did not land — the guard against gh falling back to the tip-of-default-branch behavior described above.
If gh release create fails after the tag is already pushed, do not rerun the whole block — it will stop at git tag, which is correct. Rerun only the final command.
The Publish to npm + MCP Registry workflow runs automatically: it npm publishes with provenance, polls the registry until the tarball is available, then pushes the matching server.json to the MCP Registry via mcp-publisher.

The workflow skips npm publish cleanly if the version is already on npm (cutover guard for releases that were partially published manually).

Publishing auth — npm Trusted Publishing (no token)

Publishing uses npm Trusted Publishing via OIDC — there is no NPM_TOKEN secret. The workflow's id-token: write permission is exchanged for a short-lived, one-shot publish token at publish time, using the trusted-publisher binding configured for @lazyants/lexware-mcp-server in the npm web UI. The only setup required is that trusted-publisher binding on npm; nothing needs to be stored in repository secrets.

Disclaimer

This is an unofficial, independent community project. It is not affiliated with, endorsed by, sponsored by, or supported by Lexware GmbH, Haufe Group, or any of their affiliates. For official Lexware support, contact Lexware directly — issues with this MCP server should be reported here, not to Lexware.

"Lexware" and "Lexware Office" are trademarks of their respective owners and are used in this project's name and documentation under nominative fair use, solely to identify the third-party API this client connects to.

Create, update, and delete operations modify real business data in your Lexware account. The authors provide this software "as-is" and accept no responsibility for unintended changes, data loss, or any other damages arising from its use. Test against a sandbox or non-critical account before running write operations against production data.

License

FSL-1.1-MIT — see LICENSE for the full terms.

Available Tools

66 tools

lexware_create_articleCreate ArticleD

Create a new article.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Article JSON. Key fields: title (string), type ("PRODUCT"\|"SERVICE"), unitName, unitPrice (object with currency, netAmount, grossAmount, taxRatePercentage), description

TDQS

D1.6/5.0

Behavior2/5

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

The description is consistent with annotations (readOnlyHint=false, destructiveHint=false) but adds no additional behavioral context. It does not disclose side effects, return behavior, or consequences of creation (e.g., duplicates, ID generation). The annotations already cover safety but the description should add value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is a single short sentence but is under-specified. It is concise but not informative, failing to front-load key details that would help an agent use the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is extremely incomplete given the tool's complexity (nested object with important fields like type, unitPrice). It does not explain what an article is in the Lexware context, nor does it mention return values or behavior. The schema provides some info but the description fails to add context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100% as the input schema already describes the 'body' parameter and its key fields. The description adds no extra meaning beyond what the schema provides. With full coverage, baseline is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new article.' is a tautology of the tool name 'lexware_create_article'. It fails to specify what an article is (e.g., product or service in Lexware) and does not distinguish this from other create tools like lexware_create_contact or lexware_create_invoice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance provided. The description does not indicate when to use this tool over alternatives, such as when to create an article versus a contact or invoice. No prerequisites or context are mentioned.

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

lexware_create_contactCreate ContactC

Create a new contact.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Contact JSON. Key fields: version (0 for new), roles (object with customer/vendor), company (object with name), person (object with firstName, lastName), addresses (object with billing/shipping arrays), emailAddresses, phoneNumbers

TDQS

C2.5/5.0

Behavior2/5

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

Annotations already indicate a write operation (readOnlyHint=false) and no destruction (destructiveHint=false). The description adds no further context about behavior like duplicate handling, required permissions, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is a single sentence, which is concise. However, it sacrifices substance for brevity, missing opportunities to provide helpful context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is provided, and the description does not explain return values or error conditions. For a create tool with a complex nested parameter, more guidance is needed on what happens after creation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema has 100% description coverage for the 'body' parameter, listing key fields. The tool description adds zero parameter info, so it meets the baseline but provides no extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new contact.' states the verb and resource clearly, but it is a near-tautology of the title 'Create Contact' and does not distinguish this tool from sibling create tools like lexware_create_article.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., update_contact for edits) or any exclusions. The description lacks context for decision-making.

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

lexware_create_credit_noteCreate Credit NoteB

Create a new credit note in Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Credit note JSON body. Key fields: voucherDate, address (object with contactId or manual fields), lineItems (array with name, quantity, unitPrice, etc.), totalPrice (object), taxConditions (object). See Lexware API docs for full schema.

TDQS

B3.3/5.0

Behavior3/5

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

The description does not add behavioral details beyond what annotations already indicate (readOnlyHint=false, destructiveHint=false). It offers no insights into side effects, required permissions, or reversibility, but does not contradict annotations.

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?

The description is a single concise sentence that immediately states the purpose. It is front-loaded and contains no unnecessary words, though it could be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the nested input schema and absence of output schema, the description is too minimal. It omits details about prerequisites, error handling, or effects after creation, leaving significant gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema provides a description for the 'body' parameter listing key fields, so schema coverage is 100%. The tool description itself adds no additional semantic value beyond referencing the API docs.

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?

The description clearly states the action ('Create'), the resource ('credit note'), and the system ('in Lexware'). It distinguishes this tool from other create tools like lexware_create_invoice or lexware_create_quotation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., when to create a credit note instead of an invoice or delivery note). The description lacks context on prerequisites or usage scenarios.

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

lexware_create_delivery_noteCreate Delivery NoteC

Create a new delivery note in Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Delivery note JSON body. Key fields: voucherDate, address (object with contactId or manual fields), lineItems (array with name, quantity, unitPrice, etc.), totalPrice (object), taxConditions (object). See Lexware API docs for full schema.

TDQS

C2.9/5.0

Behavior2/5

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

The description adds no behavioral details beyond what annotations provide (e.g., that it is not read-only, not destructive). It does not mention API behavior like idempotency or side effects.

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?

The description is very concise (one sentence, five words) and front-loaded with the core purpose. However, it could benefit from additional context without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with a complex nested body parameter and no output schema, the description lacks sufficient detail about return values, error states, or usage constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100% (body parameter has a detailed description with key fields); the tool description adds no additional parameter information, so baseline 3 applies.

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?

The description clearly states the action (create) and resource (delivery note) but does not differentiate it from sibling create tools like create_invoice or create_credit_note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; lacks context or prerequisites for creating a delivery note.

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

lexware_create_event_subscriptionCreate Event SubscriptionA

Create a new webhook event subscription in Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`eventType`	Yes	Event type. Documented values: contact.changed, contact.deleted, voucher.created, voucher.changed, voucher.deleted, invoice.created, invoice.changed, invoice.deleted, credit-note.created, credit-note.changed, credit-note.deleted, quotation.created, quotation.changed, quotation.deleted, delivery-note.status.changed, order-confirmation.status.changed. Lexware may add new types — pass any documented value.
`callbackUrl`	Yes	Webhook URL

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds no extra behavioral context beyond what annotations provide, such as side effects, authentication needs, or rate limits. Credit is given for not contradicting annotations, but no additional value is added.

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?

The description is a single concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simple two-parameter structure and the presence of annotations covering behavioral hints, the description adequately states the core function. However, it lacks information about return values or potential errors, which would be useful for complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100% as both eventType and callbackUrl have detailed descriptions in the schema. The description itself does not add any new semantic meaning beyond the schema, so the baseline score of 3 applies.

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?

The description clearly states 'Create a new webhook event subscription in Lexware,' specifying the action (create) and the resource (webhook event subscription). It distinguishes itself from sibling tools like lexware_create_contact or lexware_delete_event_subscription by focusing on creating subscriptions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., get, list, delete subscription tools) or prerequisites like having a valid callback URL. It lacks explicit context for appropriate usage scenarios.

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

lexware_create_invoiceCreate InvoiceA

Create a new invoice in Lexware. Set finalize=true to immediately finalize (status "open"); omit or false to create as draft. The Lexware API does not support finalizing an existing draft — this is the only documented way to obtain a finalized invoice.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Invoice JSON body. Key fields: voucherDate, address (object with contactId or manual fields), lineItems (array with name, quantity, unitPrice, etc.), totalPrice (object), taxConditions (object). See Lexware API docs for full schema.
`finalize`	No	When true, creates the invoice in finalized "open" status. When false or omitted, creates as draft. Maps to the documented ?finalize=true query parameter.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds key behavioral traits: creation with finalize=true is the only way to obtain a finalized invoice, and drafts cannot be finalized later. This goes beyond the annotations without contradicting them.

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?

The description is two sentences: the first delivers the primary purpose and key parameter behavior, the second provides an essential caveat. No extraneous information, perfectly concise and front-loaded.

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?

Given the complexity (nested body, no output schema), the description covers the critical behavioral nuance and parameter semantics. It does not specify the return value, but many creation tools implicitly return the created object. The description is nearly complete for an agent to understand when and how to invoke the 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% with detailed descriptions for both parameters. The description adds further context for the finalize parameter, especially the limitation about drafts. For the body parameter, the schema already lists key fields, so the description does not add much, but overall the combination is sufficient.

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?

The description explicitly states 'Create a new invoice in Lexware', specifying both the action (create) and the resource (invoice). Among many sibling tools like lexware_create_credit_note and lexware_create_quotation, this clearly distinguishes the tool for invoices. The finalize parameter detail further clarifies the specific output.

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?

The description provides clear guidance on when to set finalize=true (for immediate finalization) versus omit/false (draft). It also warns that finalizing an existing draft is not supported, which is critical context. However, it does not explicitly compare with other create tools for different document types, though the purpose implies use only for invoices.

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

lexware_create_order_confirmationCreate Order ConfirmationC

Create a new order confirmation in Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Order confirmation JSON body. Key fields: voucherDate, address (object with contactId or manual fields), lineItems (array with name, quantity, unitPrice, etc.), totalPrice (object), taxConditions (object). See Lexware API docs for full schema.

TDQS

C2.9/5.0

Behavior2/5

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

The description does not add behavioral context beyond annotations. Annotations indicate readOnlyHint=false (write operation) and openWorldHint=true (possible external side effects), but the description only states 'Create' without elaborating on side effects, auth requirements, or idempotency.

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?

The description is a single concise sentence that conveys the purpose without any unnecessary words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex nested object parameter and no output schema, the description lacks information about return values, error conditions, or post-creation behavior. The annotation openWorldHint=true hints at external effects but is not explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100% for the single parameter 'body', and its description lists key fields (voucherDate, address, lineItems, etc.). The tool description itself adds no extra parameter info, so baseline 3 is appropriate.

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?

The description clearly states the action (Create) and resource (order confirmation in Lexware). While it doesn't explicitly distinguish from sibling tools with similar 'create' names, the resource name is specific enough to avoid confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines provided. The description does not indicate when to use this tool versus alternatives like create_invoice or create_credit_note, nor does it mention any prerequisites or constraints.

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

lexware_create_quotationCreate QuotationC

Create a new quotation in Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Quotation JSON body. Key fields: voucherDate, expirationDate, address (object with contactId or manual fields), lineItems (array with name, quantity, unitPrice, etc.), totalPrice (object), taxConditions (object). See Lexware API docs for full schema.

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already indicate readOnlyHint=false (mutation), but the description adds no behavioral details beyond 'create.' It does not mention potential side effects, error states, or output behavior. With no annotation contradiction, but minimal value added, this scores low.

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?

The description is a single concise sentence with no unnecessary words. It is well-structured for quick reading, though it might be too minimal for some contexts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (nested object, no output schema, multiple sibling tools), the description is incomplete. It does not explain return values, error handling, or success behavior, leaving the agent without enough context to use the tool reliably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The sole parameter 'body' has 100% schema coverage, with the description in the schema listing key fields. The tool description merely states 'Quotation JSON body,' adding no extra meaning beyond the schema. Baseline 3 is appropriate.

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?

The description clearly states 'Create a new quotation in Lexware,' specifying the action (create) and resource (quotation). However, it does not differentiate from sibling tools like lexware_create_invoice or lexware_create_credit_note, which have similar structures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or scenarios where another tool would be more appropriate.

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

lexware_create_voucherCreate VoucherC

Create a new bookkeeping voucher in Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Voucher JSON. Key fields: type ("salesinvoice"\|"salescreditnote"\|"purchaseinvoice"\|"purchasecreditnote"), voucherNumber, voucherDate, totalGrossAmount, totalTaxAmount, taxType, voucherItems (array), contactId

TDQS

C2.8/5.0

Behavior2/5

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

Annotations provide only basic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds no behavioral context. Important details like duplicate handling, validation, or side effects are missing, leaving the agent with insufficient understanding of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is a single sentence, which is concise but lacks critical information that would make it earn its place. It is not wasteful, but it is insufficiently informative for an agent to use the tool correctly among many siblings.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of multiple sibling tools and a nested parameter with no output schema, the description is too brief. It fails to explain the tool's role relative to other create tools or what the return value looks like, leaving a significant knowledge gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema already covers 100% of parameters with a description listing key fields, so the tool description adds no additional meaning beyond the schema. The parameter semantics are adequate but not enhanced.

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?

The description clearly states the tool creates a 'new bookkeeping voucher' in Lexware, identifying the specific verb and resource. However, it does not distinguish this tool from sibling tools like lexware_create_invoice or lexware_create_credit_note, which could create confusion about when to use each.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. Given the many sibling create tools for specific voucher types (e.g., invoice, credit note), this omission forces the agent to infer usage from the schema's 'type' field, which is not explicitly mentioned.

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

lexware_deeplink_contactDeeplink ContactA

Read-onlyIdempotent

Get a direct URL to view a contact in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Contact ID

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds no new behavioral context beyond 'Get a direct URL', which is consistent but not additive.

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?

Single sentence, 14 words, verb-first, no redundancy. Every word earns its place.

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?

Simple tool with one parameter; description explains purpose. No output schema needed, but could mention URL format or authentication context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with description 'Contact ID'. The tool description does not add further meaning to the parameter.

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?

The description clearly states it returns a direct URL to view a contact in the Lexware web app. It uses a specific verb 'Get' and resource, and distinguishes from sibling deeplink tools for other entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives. The naming implies it's for contacts, but no when-not or comparisons with sibling tools.

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

lexware_deeplink_credit_noteDeeplink to Credit NoteA

Read-onlyIdempotent

Get a direct link to view/edit a credit note in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Credit note UUID

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description adds some value by specifying 'direct link' and 'view/edit' capabilities. However, it does not disclose the return format (e.g., a URL), rate limits, or authentication requirements. With annotations covering the safety profile, a score of 3 is appropriate.

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?

The description is a single, front-loaded sentence of 15 words. It contains no filler, no redundancy, and every word contributes to the purpose. Very concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter, no-output-schema tool with good annotations, the description is adequate but incomplete. It explains what the tool does and the required id, but does not describe what the function returns (e.g., a URL string) or error handling for invalid ids. An agent might need more detail to use the return value correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% for the single parameter 'id', which already has a description ('Credit note UUID'). The tool description does not add any additional meaning or context beyond what the schema provides. Baseline 3 is correct as the description offers no extra semantic value.

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?

The description clearly states the tool's action: 'Get a direct link to view/edit a credit note in the Lexware web app.' It specifies the verb 'Get', the resource 'direct link to a credit note', and the scope 'view/edit'. Among sibling deeplink tools (e.g., deeplink_invoice), this one uniquely targets credit notes, providing clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like lexware_get_credit_note, lexware_download_credit_note_file, or other deeplink tools. It does not mention prerequisites, exclusions, or scenarios where another tool would be more appropriate. Usage context is implied but not explicit.

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

lexware_deeplink_delivery_noteDeeplink to Delivery NoteA

Read-onlyIdempotent

Get a direct link to view/edit a delivery note in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Delivery note UUID

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's claim of returning a link is consistent but adds little behavioral context beyond what annotations provide.

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?

The description is a single, compact sentence that conveys the essential information with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and lack of output schema, the description is minimally complete but fails to describe the return format (e.g., a URL string) or error conditions, leaving some ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%; the description adds no additional meaning beyond the schema's definition of the 'id' parameter as a 'Delivery note UUID'.

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?

The description clearly states the action ('get a direct link') and the resource ('delivery note'), which distinguishes it from other deeplink tools for different entities among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like lexware_get_delivery_note or lexware_download_delivery_note_file, nor does it mention prerequisites or context.

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

lexware_deeplink_down_payment_invoiceDeeplink to Down Payment InvoiceA

Read-onlyIdempotent

Get a direct link to view/edit a down payment invoice in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Down payment invoice UUID

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds 'view/edit' implying the link may open an editable interface, but doesn't disclose potential side effects or response format. No contradiction.

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?

Single sentence, extremely concise, front-loaded with purpose. No wasted words.

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 simple deeplink tool with good annotations, the description is mostly complete. However, it does not specify the output format (e.g., a URL string), which would be helpful for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with a clear description of the 'id' parameter. Description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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?

Description clearly states the tool provides a direct link to view/edit a down payment invoice, which is specific and distinguishes it from sibling deeplink tools for other document types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool over alternatives or when not to use it. The context of 'deeplink' implies usage, but given many sibling tools, more guidance would help.

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

lexware_deeplink_dunningDeeplink to DunningB

Read-onlyIdempotent

Get a direct link to view/edit a dunning in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Dunning UUID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no further behavioral context beyond what is already stated in the annotations, which is acceptable but adds minimal value.

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?

The description is a single clear sentence with no unnecessary words. It is appropriately front-loaded and concise.

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 simple link-retrieval tool with comprehensive annotations and a single well-described parameter, the description is adequate. It covers the core purpose, though it could optionally note that the link enables viewing or editing in the web app.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema has 100% description coverage for the single parameter 'id' (described as 'Dunning UUID'). The description does not add any additional meaning or context beyond the schema, meeting the baseline for high coverage.

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?

The description clearly states the action ('Get a direct link') and the resource ('a dunning'). It distinguishes from sibling deeplink tools which target other entities, but does not explicitly differentiate from other dunning-related tools like get_dunning or pursue_dunning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs alternatives. For example, it doesn't mention that this is for generating a UI link versus retrieving data programmatically, nor does it reference sibling tools.

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

lexware_deeplink_fileDeeplink to Files InboxA

Read-onlyIdempotent

Get a direct link to the bookkeeping inbox of newly-uploaded files in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, fully covering safety and idempotency. The description adds context about the target (inbox of newly-uploaded files) but does not reveal additional behavioral traits beyond what annotations provide.

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?

The description is a single concise sentence with no redundant words. It efficiently communicates the tool's purpose without exceeding its scope.

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 simple no-parameter, no-output-schema tool, the description is complete. It specifies the return type (direct link) and the exact context (bookkeeping inbox of newly-uploaded files), leaving no ambiguity.

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?

Tool has zero parameters and schema coverage is 100%. According to rubric, baseline for 0 parameters is 4. Description adds no parameter information as none exist.

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?

The description clearly states it provides a direct link to the bookkeeping inbox for newly-uploaded files. It uses specific verb 'get' and identifies the resource, distinguishing it from sibling deeplink tools focused on specific document types like vouchers or invoices.

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?

The description implies usage for obtaining a link to the files inbox, which is distinct from other deeplink tools. While it doesn't explicitly state when not to use alternatives, the context is clear enough for an agent to select it appropriately.

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

lexware_deeplink_invoiceDeeplink to InvoiceA

Read-onlyIdempotent

Get a direct link to view/edit an invoice in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Invoice UUID

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already mark the tool as readOnly, non-destructive, idempotent, and not open-world. The description adds minimal behavioral context (view/edit), but does not explain if the link expires or requires authentication. No contradiction with 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?

The description is a single, front-loaded sentence of 12 words that conveys the core purpose without any fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool without an output schema, the description is minimally adequate. However, it would benefit from clarifying the link format or response structure, as the agent only knows it returns 'a direct link' but not in what form (e.g., plain string, JSON).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The schema has 100% coverage for the single parameter 'id' with a detailed format description. The tool description does not add new meaning beyond stating the resource type. Baseline 3 applies.

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?

The description clearly states the action ('Get'), the resource ('a direct link to view/edit an invoice'), and it effectively distinguishes this tool from its siblings such as lexware_get_invoice which returns invoice data, not a link.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used when a link to view/edit an invoice is needed, but it lacks explicit guidance on when to use it versus alternatives (e.g., lexware_get_invoice for data). It also does not mention prerequisites like the invoice existing.

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

lexware_deeplink_order_confirmationDeeplink to Order ConfirmationA

Read-onlyIdempotent

Get a direct link to view/edit an order confirmation in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Order confirmation UUID

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no new behavioral details beyond confirming it returns a link. No contradictions.

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?

Single sentence that is front-loaded with the core purpose ('Get a direct link') and no extraneous words.

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 simple tool with one parameter, annotations, and no output schema, the description is complete enough. It explains the tool's function and the required input.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema already fully describes the single parameter (order confirmation UUID) with 100% coverage. Description adds context that the link is for viewing/editing, but baseline 3 is appropriate.

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?

The description clearly states the tool returns a deeplink for an order confirmation, distinguishing it from sibling tools like lexware_get_order_confirmation (data retrieval) and other deeplink tools for different entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this versus alternatives. Usage is implied by the tool's nature (deeplink), but no exclusions or context for choosing it over other tools.

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

lexware_deeplink_quotationDeeplink to QuotationA

Read-onlyIdempotent

Get a direct link to view/edit a quotation in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Quotation UUID

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds context about viewing/editing but does not disclose link behavior (e.g., expiry, authentication). No contradictions.

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?

Single sentence of 13 words, front-loaded with purpose. No unnecessary 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?

Given the tool's low complexity (1 param, no output schema), the description is adequate. However, it could mention the return format or link behavior, but this is not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with a single 'id' parameter described as 'Quotation UUID'. The description adds no further meaning beyond the schema. Baseline of 3 is appropriate.

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?

The description clearly states the verb 'Get', the resource 'direct link to view/edit a quotation', and the context 'Lexware web app'. It distinctly differentiates from sibling deeplink tools by specifying 'quotation'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives like get_quotation or download_quotation_file. It does not specify prerequisites or when a deeplink is preferable.

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

lexware_deeplink_recurring_templateDeeplink to Recurring TemplateA

Read-onlyIdempotent

Get a direct link to view/edit a recurring invoice template in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Recurring template UUID

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, matching the description's 'Get' action. Description adds no extra behavioral context like link expiration or permissions, but does not contradict 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?

Single sentence, concise and front-loaded. No wasted words, all essential information is present.

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?

Simple tool with one parameter, no output schema. Description and annotations together provide complete context for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema has 100% description coverage for the single 'id' parameter (UUID). Description adds no extra meaning beyond the schema, meeting the baseline for high schema coverage.

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?

Description clearly states verb 'Get', resource 'direct link to view/edit a recurring invoice template', and context 'in the Lexware web app'. It distinguishes from sibling deeplink tools targeting other entities like vouchers, invoices, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage for generating a deeplink for recurring templates but provides no explicit when-to-use or when-not-to-use guidance compared to sibling deeplink tools.

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

lexware_deeplink_voucherDeeplink to VoucherA

Read-onlyIdempotent

Get a direct link to view/edit a bookkeeping voucher in the Lexware web app.

ParametersJSON Schema

Name	Required	Description	Default
`voucherId`	Yes	Voucher UUID

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it returns a link, confirming the non-mutating nature, but does not disclose additional behavioral traits like authentication requirements or rate limits.

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?

The description is a single, concise sentence that efficiently conveys the tool's purpose without any extraneous information. It is front-loaded and every word is necessary.

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?

Despite having no output schema, the description implicitly defines the return value as a link. Combined with one well-documented parameter and annotations covering safety, the description is fully sufficient for a simple, non-mutating deep-link tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema has only one parameter (voucherId) with 100% description coverage via 'Voucher UUID'. The description adds no additional meaning beyond what the schema provides, meeting the baseline for complete schema coverage.

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?

The description clearly states the verb 'Get', the resource 'direct link to a bookkeeping voucher', and the context 'in the Lexware web app'. It distinguishes from sibling tools like 'get_voucher' (retrieves data) and 'update_voucher' (modifies), as well as other deeplink tools by specifying voucher.

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?

The description explicitly states the tool's purpose as getting a direct link for viewing/editing, which implies it is used when UI navigation is needed. It does not explicitly mention when not to use it or suggest alternatives, but the clear purpose and differentiation from data-retrieval tools provide sufficient guidance.

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

lexware_delete_articleDelete ArticleB

DestructiveIdempotent

Delete an article by ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Article ID

TDQS

B3.1/5.0

Behavior2/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description 'Delete' aligns with these, but adds no further behavioral context such as whether deletion is permanent, reversible, or has side effects on related records.

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?

The description is extremely concise at six words, front-loading the action and target. However, it could optionally include a bit more context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks information about the operation's outcome (e.g., no output schema, no indication of return value or success confirmation). For a destructive tool, additional context about irreversibility or confirmation steps would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

With schema description coverage at 100% and only one parameter ('id' described as 'Article ID'), the description adds no additional meaning beyond the input schema. Baseline 3 is appropriate.

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?

The description 'Delete an article by ID' clearly states the verb (delete), resource (article), and method (by ID). This effectively distinguishes it from CRUD sibling tools like lexware_create_article, lexware_get_article, and lexware_update_article.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, consequences, or situations where deletion might be inappropriate (e.g., cascading effects, soft delete behavior).

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

lexware_delete_event_subscriptionDelete Event SubscriptionA

Destructive

Delete a webhook event subscription from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Event subscription UUID

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already indicate destructiveHint: true, and the description confirms deletion. No additional behavioral details (e.g., irreversibility, required permissions) are added beyond what annotations provide.

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?

The description is a single, direct sentence without unnecessary words. It is front-loaded and efficient.

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 single-parameter destructive tool with no output schema, the description is mostly adequate. However, it could mention the effect (e.g., permanent removal) to complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

With 100% schema description coverage, the parameter 'id' is already well-documented. The tool description adds no extra meaning or context for the parameter.

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?

The description clearly states the action ('Delete') and the resource ('webhook event subscription'), making it distinct from sibling tools like create or get operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as listing subscriptions first or understanding consequences of deletion. The description lacks context for appropriate usage.

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

lexware_download_credit_note_fileDownload Credit Note FileA

Read-onlyIdempotent

Download the file for a credit note. Defaults to PDF; pass format="xml" to request the XRechnung XML e-invoice when available (the API returns whatever representation it can render).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Credit note UUID
`format`	No	Representation to request: "pdf" (default) or "xml" for the XRechnung XML e-invoice when available.	pdf

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds useful context: the default format is PDF, the XML parameter requests the XRechnung e-invoice, and the API returns 'whatever representation it can render'. This provides clarity on the tool's behavior beyond 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?

Two sentences, no wasted words, front-loaded with the primary action. Every sentence adds value.

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 download tool with no output schema, the description provides essential context: default format, optional XML, and API behavior. It could mention the file type or content returned, but the parameter descriptions cover the basics.

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 description coverage is 100%, so baseline is 3. The description enriches the 'format' parameter by explaining the default ('pdf') and the intent of 'xml' (XRechnung XML e-invoice) and noting API fallback behavior. The 'id' parameter is sufficiently described in the schema.

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?

The description clearly states 'Download the file for a credit note.' and specifies the default format (PDF) and alternative (XML for XRechnung). It effectively distinguishes from sibling tools that download other document types (e.g., invoice, quotation, delivery note).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for downloading credit note files but does not explicitly state when to use this tool versus alternatives (e.g., download_invoice_file). It lacks guidance on prerequisites or when not to use it.

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

lexware_download_delivery_note_fileDownload Delivery Note FileB

Read-onlyIdempotent

Download the PDF file for a delivery note.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Delivery note UUID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already indicate a safe, idempotent read operation. The description adds only 'PDF file' but no additional behavioral context (e.g., response format, error handling). With annotations, the bar is lower, and the description does not contradict them.

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?

The description is a single, short sentence that conveys the essential action without unnecessary words. It is front-loaded and efficient.

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?

Given the simplicity of the tool (one parameter, no output schema, full annotation coverage), the description is nearly complete. It could mention that the response is a PDF binary, but the schema and annotations cover the safety profile adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema already fully describes the single 'id' parameter as a UUID with a description. The description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.

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?

The description clearly states the tool downloads a PDF file for a delivery note. It specifies the verb (Download) and resource (PDF file for a delivery note), but it does not differentiate from sibling download tools beyond the document type, making it slightly less specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs. alternatives (e.g., other download_file tools). The context is implied by the required parameter, but explicit conditions or exclusions are missing.

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

lexware_download_down_payment_invoice_fileDownload Down Payment Invoice FileA

Read-onlyIdempotent

Download the file for a down payment invoice. Defaults to PDF; pass format="xml" to request the XRechnung XML e-invoice when available (the API returns whatever representation it can render).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Down payment invoice UUID
`format`	No	Representation to request: "pdf" (default) or "xml" for the XRechnung XML e-invoice when available.	pdf

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds value by noting the API 'returns whatever representation it can render,' which hints at potential fallback behavior beyond the schema.

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?

Two sentences, immediately front-loaded with the main action. Every sentence adds necessary information with no redundancy or filler.

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?

Given the tool is a simple download with two well-documented parameters and no output schema, the description covers the essential behavior and format options. It could mention response type (e.g., binary file), but the context of similar download tools in the list implies standard file download handling.

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 baseline is 3. The description adds nuance about the format parameter: it indicates that XML is for XRechnung e-invoice and notes availability ('when available'), which is not fully captured in the schema description.

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?

The description clearly states the tool downloads a file for a down payment invoice, specifically differentiating it from sibling download tools for other document types. It mentions default PDF and optional XML format, making the purpose unambiguous.

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?

The description tells when to use each format: default PDF, or pass format='xml' for XRechnung XML when available. It does not explicitly exclude alternatives, but the tool name and context make it clear this is for down payment invoices only.

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

lexware_download_dunning_fileDownload Dunning FileA

Read-onlyIdempotent

Download the PDF file for a dunning.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Dunning UUID

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no further behavioral context, such as return format or error scenarios, so it meets the baseline but does not exceed it.

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?

The description is a single, concise sentence with no waste. It is front-loaded and efficiently states the tool's action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple with one parameter and annotations cover safety, the description lacks details about output format (e.g., PDF binary) and potential error conditions. It is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The schema covers 100% of the parameter 'id' with a clear description 'Dunning UUID'. The description adds no additional semantics beyond what the schema provides.

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?

The description 'Download the PDF file for a dunning' uses a specific verb ('Download') and resource ('PDF file for a dunning'), clearly distinguishing it from sibling tools like lexware_download_credit_note_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as other download tools or when prerequisites (e.g., the dunning must exist) are needed.

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

lexware_download_fileDownload FileB

Read-onlyIdempotent

Download a file from Lexware. Returns the file as base64-encoded content.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	File UUID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare the tool as read-only, non-destructive, idempotent, and open-world. The description adds that it returns base64 content, which is helpful but does not disclose other behavioral traits like file size limits or error handling.

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?

The description is extremely concise at two sentences, front-loading the action and output format without any fluff. Every word is meaningful.

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 simple one-parameter tool, the description provides essential information (base64 output) and sufficient context for invocation. However, it could be more complete by mentioning that this tool is for generic file downloads not covered by specific document-type download tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema has 100% coverage with a description of the 'id' parameter as 'File UUID'. The tool description adds no additional meaning beyond that, so the baseline score of 3 applies.

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?

The description clearly states the action ('Download'), the resource ('a file from Lexware'), and the output format ('base64-encoded content'). However, it does not differentiate this generic download tool from the many sibling tools for specific document types (e.g., lexware_download_invoice_file), which could cause confusion about when to use this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the specific download tools for invoices, credit notes, etc. The agent is left to infer based on the naming convention, which is not explicitly explained.

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

lexware_download_invoice_fileDownload Invoice FileA

Read-onlyIdempotent

Download the file for an invoice. Defaults to PDF; pass format="xml" to request the XRechnung XML e-invoice when available (the API returns whatever representation it can render).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Invoice UUID
`format`	No	Representation to request: "pdf" (default) or "xml" for the XRechnung XML e-invoice when available.	pdf

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint, idempotentHint, and non-destructive. The description adds that the API returns whatever representation it can render, which clarifies behavior beyond annotations. No contradiction.

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?

Two sentences, no wasted words. Every clause adds value: verb+resource, default behavior, optional parameter, caveat on API behavior.

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?

Given simple parameters (2, one optional) and no output schema, the description adequately covers what the tool does and what to expect. Annotations confirm safety. No missing critical information.

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 provides full parameter descriptions (100% coverage). The description adds context beyond schema: default to PDF, XML for XRechnung, and that the API returns whatever it can render. This helps the agent understand the behavior of the format parameter.

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?

The description clearly states the action (download) and resource (invoice file). It specifies the default format (PDF) and an alternative format (XML). Among many sibling download tools, the name and description uniquely identify this tool for invoice files.

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?

The description implies usage for downloading invoice files. It doesn't explicitly list alternatives, but the tool name and context among sibling download tools make the purpose clear. The added note about format="xml" provides guidance on optional usage.

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

lexware_download_order_confirmation_fileDownload Order Confirmation FileB

Read-onlyIdempotent

Download the PDF file for an order confirmation.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Order confirmation UUID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already indicate safe read-only, non-destructive, idempotent behavior. The description adds no further behavioral context beyond confirming the download action.

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?

The description is a single sentence, efficient and front-loaded with the key action and resource. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple download tool with one parameter and no output schema, the description covers the basics. However, it lacks details on error handling or prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema fully describes the single parameter (id as UUID). The description repeats 'order confirmation' but adds no extra meaning beyond the schema.

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?

The description clearly states the action (Download) and the resource (PDF file for an order confirmation). It differentiates from sibling tools for other document types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like lexware_download_file or other download tools. The description provides no context for selection.

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

lexware_download_quotation_fileDownload Quotation FileA

Read-onlyIdempotent

Download the PDF file for a quotation.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Quotation UUID

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating a safe read operation. The description adds that the output is a PDF file, which is useful context beyond the 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?

The description is a single 5-word sentence with no extra fluff. Every word is necessary and front-loaded. Ideal conciseness.

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 simple download tool with one parameter and clear annotations, the description covers the essential information. The lack of an output schema is acceptable for a file download. Could mention response format explicitly, but overall complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema covers 100% of parameters with a description for id ('Quotation UUID'). The description adds no additional meaning; it only restates the resource type. Baseline score of 3 is appropriate.

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?

The description 'Download the PDF file for a quotation' clearly states the action (download) and resource (PDF file for a quotation), and the name and title are consistent. It effectively distinguishes from sibling tools like lexware_download_invoice_file.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a quotation UUID is available, but provides no explicit guidance on when to use vs. alternatives, nor any prerequisites or exclusions. It is adequate but lacks depth.

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

lexware_get_articleGet ArticleA

Read-onlyIdempotent

Get a single article by ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Article ID

TDQS

A3.8/5.0

Behavior3/5

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

Description adds no behavioral details beyond what annotations already provide (readOnlyHint, idempotentHint, etc.). Annotations are sufficient, but description does not mention behavior on missing ID, permissions, or return format.

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?

Single sentence with no unnecessary words. Every part is relevant and front-loaded.

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 simple single-get tool with one parameter and no output schema, the description is adequate. However, it could optionally mention that the return value is the full article object.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema provides a description for the single parameter 'id', and schema coverage is 100%. Tool description adds no additional context beyond the schema, meeting the baseline of 3.

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?

Description clearly states verb (Get), resource (article), and scope (single by ID). Distinguishes itself from sibling tools like lexware_list_articles (list) and lexware_create_article (create).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description says 'by ID', implying use when an ID is known. However, it does not explicitly state when to use this tool over alternatives (e.g., list_articles for browsing), nor does it provide exclusion criteria or prerequisites.

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

lexware_get_contactGet ContactA

Read-onlyIdempotent

Get a single contact by ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Contact ID

TDQS

A3.9/5.0

Behavior3/5

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

Annotations fully cover safety (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). The description adds no further behavioral traits (e.g., authentication needs, rate limits). With annotations present, this is adequate but minimal.

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?

The description is extremely concise—five words—with no unnecessary information. It is front-loaded and immediately clear.

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 simple read-only tool with one parameter, the description is complete. Annotations cover behavioral aspects, and no output schema is needed for a straightforward retrieval. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with the 'id' parameter already described as 'Contact ID'. The description's 'by ID' adds no new meaning beyond the schema. Baseline 3 is appropriate.

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?

The description 'Get a single contact by ID' uses a specific verb ('Get') and resource ('contact'), clearly indicating the tool retrieves one contact. It distinguishes itself from siblings like lexware_list_contacts (lists multiple) and lexware_create_contact (creates).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have a contact ID, but it does not explicitly state when to use this tool over alternatives like lexware_list_contacts (to find an ID) or when not to use it. No context on prerequisites or exclusions is provided.

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

lexware_get_credit_noteGet Credit NoteA

Read-onlyIdempotent

Retrieve a credit note by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Credit note UUID

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description only adds 'Retrieve', which is consistent but does not provide additional behavioral detail beyond what annotations offer.

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?

The description is a single, clear sentence of six words, perfectly front-loaded with the verb and resource, with no unnecessary words.

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 simple get-by-ID tool with full schema coverage and informative annotations, the description is mostly adequate. However, it lacks any mention of return value structure, which would be helpful given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% and the parameter 'id' is well-described with format and pattern. The description adds no extra semantic meaning beyond the schema, meeting the baseline for high coverage.

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?

The description clearly states that the tool retrieves a credit note by ID from Lexware, using a specific verb and resource, which distinguishes it from sibling tools like get_article or get_invoice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any conditions or prerequisites. The description merely states what it does without any usage context.

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

lexware_get_delivery_noteGet Delivery NoteA

Read-onlyIdempotent

Retrieve a delivery note by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Delivery note UUID

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds no further behavioral context, but since annotations are sufficient, a score of 3 is appropriate.

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?

The description is a single, efficient sentence that conveys the core purpose without any extraneous 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 simple retrieval tool with one parameter and comprehensive annotations, the description sufficiently covers the necessary context. No additional details are required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

With 100% schema description coverage for the single parameter 'id', the schema already documents its purpose. The description does not add extra semantics, meeting the baseline of 3.

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?

The description explicitly states the action ('Retrieve'), the resource ('delivery note'), and the method ('by ID'). It is clear and distinct from sibling tools like list or create operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., listing delivery notes first). It does not mention prerequisites or exclude other scenarios.

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

lexware_get_down_payment_invoiceGet Down Payment InvoiceA

Read-onlyIdempotent

Retrieve a down payment invoice by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Down payment invoice UUID

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare `readOnlyHint: true`, `destructiveHint: false`, and `idempotentHint: true`, so the safe read behavior is clear. The description adds no further behavioral context, which is acceptable but not enhanced.

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?

The description is one concise sentence that communicates the essential purpose without any superfluous words. It is front-loaded with the verb and resource.

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 simple retrieval tool with one parameter and no output schema, the description is sufficiently complete. It covers the core action and resource, and annotations fill in safety details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema covers the single parameter `id` with full description (100% coverage). The description does not add additional meaning beyond what the schema provides, so baseline score 3 is appropriate.

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?

The description uses specific verb 'Retrieve' and identifies the resource 'down payment invoice' with a clear scope 'by ID'. It effectively distinguishes from sibling tools that create, delete, or list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like `lexware_get_invoice` or other retrieval tools. The description lacks context on usage conditions or exclusions.

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

lexware_get_dunningGet DunningA

Read-onlyIdempotent

Retrieve a dunning by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Dunning UUID

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds no extra behavioral context beyond what is implicit in 'retrieve'.

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?

The description is a single, efficient sentence that immediately conveys the tool's purpose without unnecessary words.

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 simple get-by-ID operation with comprehensive annotations and schema, the description is mostly complete. It does not mention the return format, but the absence of an output schema makes this less critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema has 100% description coverage for the single parameter 'id', which is described as 'Dunning UUID'. The description adds no further semantic meaning.

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?

The description clearly states the verb 'retrieve', the resource 'dunning', and the method 'by ID', effectively distinguishing it from sibling tools like create or list operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fetching a specific dunning by ID but provides no explicit guidance on when to use this tool versus alternatives or when not to use it.

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

lexware_get_event_subscriptionGet Event SubscriptionA

Read-onlyIdempotent

Retrieve a webhook event subscription by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Event subscription UUID

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description 'Retrieve' aligns with these, but adds no additional behavioral context such as error handling or response format.

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?

The description is a single concise sentence, front-loaded with the verb and resource, containing no unnecessary words.

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?

The tool is simple with one parameter and rich annotations. The description is adequate for the retrieval action but could optionally mention return details. Overall complete given the context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The schema covers the only parameter 'id' with a description and format. The description adds no extra meaning beyond 'by ID', so with 100% schema coverage the baseline of 3 is appropriate.

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?

The description clearly states the action 'Retrieve' and the resource 'webhook event subscription by ID'. It distinguishes itself from sibling tools like lexware_list_event_subscriptions by specifying retrieval by ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies using the tool when you have a specific ID, but it does not explicitly state when to use it versus alternatives like listing or creating subscriptions.

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

lexware_get_file_statusGet File StatusA

Read-onlyIdempotent

Get the processing status of an uploaded file from Lexware. Requires an API key with the file-status scope; keys without it get an access_denied error from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	File UUID

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds meaningful behavioral details: authentication scope requirement and the specific access_denied error for insufficient keys. This enriches the agent's understanding of failure modes.

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?

Two sentences with no redundancy. The first sentence states the purpose, the second provides the auth requirement and error outcome. Every word earns its place.

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 simple read-status tool with one parameter, the description covers purpose, prerequisites, and error handling. Annotations cover safety (readOnly, idempotent), and the schema covers parameter format. No significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The schema already documents the single parameter 'id' as a 'File UUID' with 100% coverage. The description adds no further parameter meaning, so it relies on the schema. Baseline 3 is appropriate given high coverage.

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?

The description clearly states the verb ('Get') and the specific resource ('processing status of an uploaded file from Lexware'). It distinguishes the tool from siblings like lexware_download_file or lexware_upload_file by focusing on status retrieval.

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?

The description provides clear context (checking upload processing status) and includes a crucial prerequisite (API key with file-status scope) with an explicit error outcome. While it doesn't name alternative tools, the purpose is unambiguous enough that an agent can infer when to use it.

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

lexware_get_invoiceGet InvoiceA

Read-onlyIdempotent

Retrieve an invoice by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Invoice UUID

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds no extra behavioral context beyond 'retrieve', which is consistent. No contradiction.

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?

One short, front-loaded sentence with no wasted words. Perfectly concise for the tool's simplicity.

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 simple retrieval tool with one parameter, rich annotations, and no output schema, the description is sufficient. It could mention that it returns the full invoice object, but the lack of output schema means the agent infers from context. Still nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with a clear description of the 'id' parameter. The description's 'by ID' adds no new meaning beyond what the schema provides.

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?

The description clearly states the verb 'retrieve', the resource 'invoice', and the method 'by ID'. It distinguishes from siblings like lexware_create_invoice or lexware_delete_invoice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description is clear about what the tool does but provides no guidance on when to use it versus alternatives (e.g., searching or listing invoices).

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

lexware_get_order_confirmationGet Order ConfirmationA

Read-onlyIdempotent

Retrieve an order confirmation by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Order confirmation UUID

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds no behavioral context beyond retrieval; it doesn't clarify what happens if the ID doesn't exist.

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?

A single concise sentence with no extraneous 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?

For a simple retrieval tool with one required parameter and no output schema, the description is nearly complete. However, it could mention error handling (e.g., if order confirmation not found).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% for the single 'id' parameter, including format and pattern. The description adds no additional meaning beyond the schema.

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?

The description uses a specific verb 'Retrieve' and resource 'order confirmation by ID', clearly distinguishing it from sibling tools like create, delete, list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied as a straightforward retrieval tool, but no explicit guidance on when to use vs alternatives (e.g., download tool) or conditions for use.

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

lexware_get_paymentsGet PaymentsB

Read-onlyIdempotent

Get payment details for a specific voucher.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Voucher UUID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations (readOnlyHint, destruptiveHint, idempotentHint, openWorldHint) adequately convey safety and idempotence. The description adds no additional behavioral details, but the annotations suffice.

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?

The description is a single, front-loaded sentence with no wasted words. It is efficient and directly communicates the tool's action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks details about return value structure, pagination, or what constitutes 'payment details.' With no output schema, more context would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema fully describes the single 'id' parameter with 100% coverage. The description does not add extra meaning, so baseline 3 is appropriate.

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?

The description clearly states the verb 'Get' and resource 'payment details for a specific voucher,' making the purpose unambiguous. It distinguishes well from sibling tools like lexware_get_voucher (which gets the voucher itself) and other get_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. Given many sibling tools (e.g., lexware_get_voucher, lexware_list_vouchers), explicit usage context is missing.

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

lexware_get_profileGet ProfileB

Read-onlyIdempotent

Get the organization profile information.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already indicate a safe, read-only, idempotent operation. The description adds the context of fetching 'organization profile information' but does not disclose any additional behavioral traits such as caching, latency, or data completeness.

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?

The description is a single, front-loaded sentence with no redundancy. Every word contributes to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description is adequate for a simple read-only tool with no parameters and no output schema, it lacks detail about the returned data. Users are left to infer what 'profile information' includes.

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?

The tool has no parameters, and the schema coverage is 100%. Per the guidelines, a baseline of 4 is appropriate since no parameter documentation is needed.

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?

The description clearly states the verb 'Get' and the resource 'organization profile information', making the purpose explicit. It distinguishes from sibling tools that retrieve other entities (e.g., get_article, get_contact) but doesn't elaborate on what the profile contains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or which tool to choose for profile-related tasks.

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

lexware_get_quotationGet QuotationA

Read-onlyIdempotent

Retrieve a quotation by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Quotation UUID

TDQS

A3.6/5.0

Behavior3/5

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

The description aligns with annotations (readOnlyHint, destructiveHint, idempotentHint) but adds no extra behavioral context beyond stating it retrieves data. Annotations already cover safety, so no contradiction.

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?

The description is a single, concise sentence with no unnecessary words. It efficiently communicates the tool's function.

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 simple retrieval tool with one parameter and no output schema, the description is largely sufficient. It lacks explicit mention of return value structure, but annotations and context signals compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% and fully describes the id parameter. The description adds no additional meaning beyond 'by ID', so baseline 3 is appropriate.

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?

The description clearly states the action 'Retrieve', the resource 'quotation', and the key parameter 'by ID'. It distinguishes itself from sibling tools like lexware_get_invoice by specifying the resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention situation-specific usage, prerequisites, or exclusions.

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

lexware_get_recurring_templateGet Recurring TemplateA

Read-onlyIdempotent

Retrieve a recurring invoice template by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Recurring template UUID

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no behavioral context beyond the annotations, so it is adequate but not enhanced.

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?

The description is a single sentence of 10 words, concise and front-loaded with the essential action and resource. No unnecessary text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has one required parameter and no output schema. The description does not mention what the response contains (e.g., full template details). Slightly incomplete for a retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% for the single parameter 'id', including format and pattern. The description does not add any additional semantic meaning beyond what the schema provides.

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?

The description clearly specifies the action (retrieve) and the resource (recurring invoice template by ID). It distinguishes from sibling tools like lexware_list_recurring_templates (list) and lexware_create_* (create).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as lexware_list_recurring_templates for finding IDs before retrieving a specific template. No when-not-to-use or context is given.

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

lexware_get_voucherGet VoucherA

Read-onlyIdempotent

Retrieve a bookkeeping voucher by ID from Lexware. The voucherStatus field in the response is normalized to its canonical lowercase form. Known values: unchecked, open, paid, paidoff, voided, transferred, sepadebit. Retries up to 3 times (1 s / 2 s / 4 s) on 404 to absorb the indexing delay after an upload; if the voucher is still missing, returns { voucherId, status: "processing", message } rather than an error. Other failures are reported as errors.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Voucher UUID

TDQS

A4.5/5.0

Behavior5/5

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

Annotations provide readOnly/idempotent hints, but description goes beyond by disclosing retry logic (3 times on 404), normalized status field, and the processing fallback return object. This is valuable behavioral context not available elsewhere.

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?

Two sentences, front-loaded with purpose, and each sentence adds critical information (normalization, retries, error handling). No unnecessary fluff.

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 simple get-by-ID tool, the description covers the essential behavioral aspects: retrieval, normalization, retry policy, and fallback response. Given no output schema, it adequately explains what the agent can expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema covers the single parameter 'id' completely with format and description. Description adds no additional semantics beyond what schema already states. Baseline 3 is appropriate as schema does full documentation.

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?

Clearly states 'Retrieve a bookkeeping voucher by ID' with specific resource and action. Distinguishes from siblings by specifying voucher rather than other document types, and adds detail about status normalization.

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?

Implies usage for fetching a single voucher by ID, and explains behavior when voucher may be absent (retries, processing fallback). Does not explicitly mention alternatives like list_vouchers, but context is clear enough.

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

lexware_list_articlesList ArticlesB

Read-onlyIdempotent

List all articles with optional pagination.

ParametersJSON Schema

Name	Required	Description
`gtin`	No	Filter by GTIN/EAN
`page`	No	Page number (0-indexed)
`size`	No	Results per page (max 250)
`type`	No	Filter by article type
`articleNumber`	No	Filter by article number

TDQS

B3.2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, providing a strong safety profile. The description adds no additional behavioral context (e.g., rate limits, data freshness) beyond what is in the schema.

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?

The description is a single sentence, efficient and without fluff. However, it could be slightly more informative by hinting at available filters (articleNumber, gtin, type) without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with 5 parameters and no output schema, the description covers the basic functionality but omits mention of filtering capabilities and return value structure, which are partially covered by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it simply restates 'optional pagination' which is already detailed in the parameter definitions.

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?

The description clearly states the verb 'list' and resource 'articles', and includes the optional pagination feature. It distinguishes well from sibling tools like lexware_get_article (single) and lexware_create_article (create), making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as lexware_get_article for specific articles or filtering via parameters. There is no mention of prerequisites or when not to use it.

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

lexware_list_contactsList ContactsA

Read-onlyIdempotent

List all contacts with optional pagination and filters.

ParametersJSON Schema

Name	Required	Description
`name`	No	Filter by name
`page`	No	Page number (0-indexed)
`size`	No	Results per page (max 250)
`email`	No	Filter by email address
`number`	No	Filter by contact number
`vendor`	No	Filter for vendors
`customer`	No	Filter for customers

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds no behavioral context beyond what annotations provide, which is acceptable but not additive.

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?

The description is a single, concise sentence (6 words) that front-loads the core purpose. Every word is necessary; no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately states the function but does not describe the output format (e.g., returns a list of contact objects, pagination metadata). Given no output schema, a brief addition on response structure would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, with each parameter having a clear description. The tool description only summarizes 'optional pagination and filters', adding minimal meaning beyond the schema. Baseline score of 3 is appropriate.

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?

The description clearly states the action ('List'), the resource ('contacts'), and the options ('optional pagination and filters'). It effectively distinguishes from sibling tools like lexware_get_contact (single contact) and other list tools for different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. It implies listing all contacts, but lacks guidance on when to use filters or pagination, or when to prefer a different tool like lexware_get_contact for a specific contact.

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

lexware_list_countriesList CountriesA

Read-onlyIdempotent

List all available countries with their tax classifications.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, covering safety and behavior. The description adds that the tool returns countries with tax classifications, which provides context beyond annotations. No contradictions.

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?

The description is a single, front-loaded sentence with no wasted words. Every part contributes meaning, making it highly concise and well-structured.

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 parameterless list tool with strong annotations, the description is largely complete. It states what is returned (countries with tax classifications). However, the absence of an output schema means the description could be enhanced by specifying the return format (e.g., array of objects with fields).

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?

The tool has no parameters, and schema coverage is 100%. The description does not need to add parameter details, and the baseline score of 4 is appropriate.

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?

The description clearly states the verb 'list' and the resource 'countries', with the additional detail 'with their tax classifications' adding specificity. It distinguishes itself from sibling list tools (e.g., lexware_list_articles) by naming the entity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when or when not to use this tool versus alternatives. While the purpose is self-evident, given many sibling list tools, a note about when to retrieve countries would improve clarity. Implicit usage is acceptable but lacking exclusions.

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

lexware_list_event_subscriptionsList Event SubscriptionsA

Read-onlyIdempotent

List all webhook event subscriptions in Lexware.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already cover safety (readOnly, non-destructive). The description adds 'all' implying no filtering, but lacks details on pagination, response format, or limits. Partially transparent.

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?

Single sentence, zero waste, front-loaded with verb and resource. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool, the description is minimal but adequate. It lacks details about return values and context like pagination or event subscription definition. Could be more complete.

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?

No parameters exist, so schema coverage is 100%. The description adds no parameter info, but none is needed. Baseline 4 applies.

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?

The description clearly states the action (list) and resource (webhook event subscriptions). It distinguishes from sibling tools like lexware_get_event_subscription and lexware_delete_event_subscription.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention context or exclusions, leaving the agent without decision support.

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

lexware_list_payment_conditionsList Payment ConditionsA

Read-onlyIdempotent

List all available payment conditions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context, such as pagination, rate limits, or the scope of 'all available conditions'.

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?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the purpose.

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?

Given the simplicity of the tool (no parameters, no output schema, and comprehensive annotations), the minimal description is complete enough for an AI agent to understand its purpose.

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?

There are no parameters, and the schema covers 100% of the (empty) parameters. According to the scoring rules, 0 parameters warrant a baseline of 4. The description adds nothing further, which is acceptable.

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?

The description 'List all available payment conditions' clearly states the action (list) and resource (payment conditions), distinguishing it from other list tools like lexware_list_contacts or lexware_list_articles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs alternatives, such as when payment conditions are needed for creating invoices or other documents.

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

lexware_list_posting_categoriesList Posting CategoriesA

Read-onlyIdempotent

List all available posting categories for bookkeeping.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the description does not need to add much. It adds the scope of 'all available' categories, but no additional behavioral context beyond 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?

The description is a single, concise sentence that directly conveys the tool's purpose with no unnecessary words.

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?

Given no parameters and annotations covering safety, the description is complete for a simple list tool. No output schema is needed for this straightforward operation.

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?

There are no parameters, so schema coverage is 100%. Baseline for 0 parameters is 4; the description adds no parameter details because none exist.

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?

The description clearly states it lists all available posting categories for bookkeeping, which is a specific verb+resource. It distinguishes from sibling list tools like list_articles or list_contacts.

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?

The description implicitly indicates when to use this tool (when you need posting categories), but it does not provide explicit when-not-to-use or alternative guidance. However, the purpose is clear enough for a simple list operation.

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

lexware_list_print_layoutsList Print LayoutsA

Read-onlyIdempotent

List available print layout templates.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, so the tool's safe nature is clear. The description adds no additional behavioral context, such as authentication or output details.

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?

The description is a single sentence, concise and to the point, with no redundant 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?

For a tool with no parameters and rich annotations, the description is adequate. However, it could mention the output format or that layouts are predefined.

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?

The tool has zero parameters, and schema coverage is 100%. The description adds no parameter info, but baseline for 0 parameters is 4.

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?

The description clearly states the tool lists available print layout templates, using a specific verb and resource, and is distinct from other list tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., other list tools). The description lacks context for tool selection.

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

lexware_list_recurring_templatesList Recurring TemplatesB

Read-onlyIdempotent

List recurring invoice templates from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page number (0-indexed)
`size`	No	Results per page (max 250)

TDQS

B3.2/5.0

Behavior2/5

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

The description only says 'list,' which is consistent with the annotations (readOnlyHint, idempotentHint), but it does not add any behavioral detail beyond what annotations already provide. For example, it does not mention pagination behavior, rate limits, or that the result returns a list of templates.

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?

The description is a single, concise sentence with only five words. It is front-loaded and contains no unnecessary 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?

For a simple list tool with good schema coverage and annotations, the description is adequately complete. It could mention that the result is a list of invoice templates, but given the tool's straightforward nature, this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100% (both page and size have descriptions). The description does not add any additional meaning beyond the schema, so it meets the baseline score of 3.

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?

The description clearly states the action ('list') and the resource ('recurring invoice templates') and specifies the source ('Lexware'). It distinguishes from sibling list tools by specifying 'recurring invoice templates,' but does not explicitly differentiate from the sibling 'get' tool (lexware_get_recurring_template) or other list tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., when to use list vs get, or which pagination parameters are appropriate). There are no usage contexts, prerequisites, or exclusion criteria.

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

lexware_list_voucherlistList VoucherlistB

Read-onlyIdempotent

Search and filter across all voucher types in Lexware. This is the main way to find invoices, credit notes, quotations, and other voucher types.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No	Page number (0-indexed)
`size`	No	Results per page (max 250)
`archived`	No	Filter by archived status
`contactId`	No	Filter by contact UUID
`contactName`	No	Wildcard filter on contactName, applied client-side after fetching. % = any sequence, _ = exactly one character. Case-insensitive. Example: "Müller%". Implies fetchAllPages.
`voucherType`	No	Voucher type(s), comma-separated, or "any" for no type filter (default). Values: invoice, creditnote, orderconfirmation, quotation, deliverynote, downpaymentinvoice, dunning, purchaseinvoice, purchasecreditnote	any
`createdDateTo`	No	Filter by creation date to (yyyy-MM-dd)
`fetchAllPages`	No	When true, follow pagination until every page is retrieved (capped at 100 requests) instead of returning a single page.
`hasOpenAmount`	No	When true, keep only entries with openAmount > 0. Applied client-side after fetching. Implies fetchAllPages.
`voucherDateTo`	No	Filter vouchers to date (ISO, e.g. "2024-12-31")
`voucherNumber`	No	Filter by voucher number
`voucherStatus`	No	Voucher status(es), comma-separated, or "any" for no status filter (default). Values: draft, open, overdue, paid, paidoff, voided, accepted, rejected, unchecked	any
`createdDateFrom`	No	Filter by creation date from (yyyy-MM-dd)
`voucherDateFrom`	No	Filter vouchers from date (ISO, e.g. "2024-01-01")

TDQS

B3.2/5.0

Behavior3/5

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

Annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false) fully cover the safety profile, and the description does not contradict them. The description itself adds only scope context (all voucher types) rather than new behavioral traits like response size or cross-type coverage behavior — that detail lives in the parameter docs. No contradiction, annotations carry the weight; solid but unexceptional 3.

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?

Two sentences, front-loaded with the verb and scope, no filler. The second sentence's enumeration of voucher types is slightly redundant with 'all voucher types' from the first, but it does add concreteness and the 'main way' positioning. Efficient overall, though one phrase could plausibly have been spent disambiguating from list_vouchers instead.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, paginated, filtering-heavy tool, the rich schema documentation and annotations carry most of the contextual load. However, with no output schema, the missing description of return shape or result behavior is a notable gap. The unaddressed ambiguity with lexware_list_vouchers further erodes completeness — a bit more description could have rounded this out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3 per the rubric. The tool description itself adds no parameter semantics, but the schema's own parameter docs are rich (wildcards, client-side filtering, 'Implies fetchAllPages', request caps, defaults). The description does not need to supplement; it just also doesn't add anything beyond the schema. Baseline 3 is correct.

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?

Clear verb ('search and filter') plus resource ('all voucher types') with explicit examples (invoices, credit notes, quotations). It does not, however, clarify how it differs from the near-identical sibling lexware_list_vouchers — the 'main way' phrasing is an assertion of primacy, not a distinction. Clear but lacking sibling differentiation, so a 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'This is the main way to find invoices...' is only a weak implication of when to use the tool. With a direct competitor sibling named lexware_list_vouchers, the total absence of an explicit when/why-this-versus-that or any exclusion reasoning is a meaningful gap. There is no naming of alternatives or when-not-to-use — essentially no usable guidance.

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

lexware_list_vouchersLook Up Vouchers by NumberA

Read-onlyIdempotent

Look up bookkeeping vouchers by voucher number. GET /vouchers is a LOOKUP endpoint, not a browsable collection: the Lexware API rejects any call without voucherNumber with HTTP 400 "voucherNumber parameter is required". To browse or filter vouchers, use lexware_list_voucherlist, which is the collection endpoint and carries the summary fields (contactName, openAmount) that /vouchers does not.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (0-indexed)
`size`	No	Results per page (max 250)
`voucherNumber`	Yes	Voucher number to look up. REQUIRED — the API returns 400 without it.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral context by disclosing the API's 400 error when voucherNumber is missing and noting that summary fields like contactName and openAmount are absent from this endpoint. This goes beyond the structured 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?

The description is three sentences long, front-loaded with the core purpose, then providing crucial usage and behavioral details. No fluff or redundant repetition; every sentence earns its place.

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 simple lookup tool, the description covers the essential information: when to use, critical parameter requirement, error behavior, and what fields are not returned. Combined with the strong annotations and full schema coverage, it is complete and actionable for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The schema already provides 100% coverage with detailed descriptions for all three parameters, including the requirement and error condition for voucherNumber. The tool description does not add new semantic information beyond what the schema already states, so the baseline 3 is appropriate.

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?

The description uses a specific verb ('Look up') and clearly identifies the resource ('bookkeeping vouchers') and the method ('by voucher number'). It explicitly distinguishes this tool from lexware_list_voucherlist by stating it is not a browsable collection, leaving no ambiguity about its purpose.

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?

The description explicitly states when to use this tool (lookup by exact number) and when not to (browsing/filtering), directing users to lexware_list_voucherlist for those cases. It also warns about the required voucherNumber parameter and the HTTP 400 error, giving clear operational guidance.

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

lexware_pursue_credit_notePursue to a Credit NoteA

Destructive

Create a new credit note as a follow-up to a preceding invoice. Maps to the documented POST /credit-notes?precedingSalesVoucherId={id}[&finalize=true] endpoint. Set finalize=true to immediately finalize the credit note; omit or false to create as draft.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Credit note JSON body. Same shape as lexware_create_credit_note. See Lexware API docs for full schema.
`finalize`	No	When true, creates the credit note in finalized status (immediately paid-off, reducing the invoice open amount). When false or omitted, creates as draft. Maps to the documented ?finalize=true query parameter.
`precedingSalesVoucherId`	Yes	UUID of the preceding invoice that this credit note is pursued from.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare destructiveHint=true, which aligns with 'Create' in description. Description adds details on finalization behavior and API mapping, providing additional context beyond 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?

Three concise sentences with key information front-loaded. No filler, each sentence adds value.

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?

Covers necessary inputs and key behavioral option (finalize). Lacks mention of return value or output shape, but overall sufficient for a straightforward create tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. Description adds context for 'finalize' and the overall purpose but adds little to the 'body' parameter beyond schema. Acceptable but not exceptional.

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?

Clearly states verb 'Create' and resource 'credit note' with specific context 'as a follow-up to a preceding invoice'. Distinguishes from sibling 'create' tools by emphasizing the pursuit relationship, and from other 'pursue' tools by specifying the resource.

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?

Provides explicit guidance on when to use (follow-up to an invoice) and details on the 'finalize' parameter. Lacks explicit alternatives or when-not-to-use, but the naming and context sufficiently differentiate from siblings.

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

lexware_pursue_delivery_notePursue to a Delivery NoteA

Create a new delivery note as a follow-up to a preceding quotation or order confirmation. Maps to the documented POST /delivery-notes?precedingSalesVoucherId={id} endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Delivery note JSON body. Same shape as lexware_create_delivery_note. See Lexware API docs for full schema.
`precedingSalesVoucherId`	Yes	UUID of the preceding sales voucher (quotation or order confirmation) that this delivery note is pursued from.

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already indicate non-readOnly, non-destructive, and non-idempotent. Description adds endpoint mapping and clarifies it's a creation operation, consistent with 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?

Two concise sentences, no extraneous information, front-loaded with core purpose.

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?

Given 2 required params, no output schema, and annotations, the description provides sufficient information for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Both parameters have schema descriptions. Description adds context: precedingSalesVoucherId as UUID of preceding document, body references sibling tool's schema for details.

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?

Clearly states 'create a new delivery note as a follow-up to a preceding quotation or order confirmation', distinguishing it from standalone creation tools like lexware_create_delivery_note.

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?

Specifies when to use (follow-up to quotation or order confirmation). Does not explicitly list when not to use, but context of sibling tools implies alternatives.

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

lexware_pursue_dunningPursue to a DunningA

Create a new dunning as a follow-up to a preceding invoice via the documented POST /dunnings?precedingSalesVoucherId={id} endpoint. Dunnings are always created in draft mode and do not need to be finalized.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Dunning JSON body. Key fields: voucherDate, address (object with contactId or manual fields), lineItems (array), totalPrice (object), taxConditions (object). See Lexware API docs for full schema.
`precedingSalesVoucherId`	Yes	UUID of the preceding invoice that this dunning is pursued from. Required by the Lexware API.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=false (write) and destructiveHint=false. The description adds that dunnings are created in draft mode and need no finalization, which is behavioral context beyond what annotations provide. It does not mention auth requirements or side effects, but the added draft mode detail is valuable.

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?

Two sentences, no redundancy. The first sentence conveys purpose and endpoint, the second adds an important behavioral note. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 2-parameter tool with no output schema, the description covers purpose and draft mode but does not explain return values, error cases, or authorization. It is slightly incomplete for a create operation, leaving the agent to infer response format from the endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with detailed descriptions for both parameters. The tool description adds minimal parameter information beyond referencing the endpoint usage of precedingSalesVoucherId. Baseline 3 is appropriate as the schema already does the heavy lifting.

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?

The description clearly states the action: 'Create a new dunning as a follow-up to a preceding invoice'. It specifies the resource (dunning), verb (create), and relationship (follow-up to invoice). The endpoint is documented, and the distinction from sibling 'pursue_*' tools is clear because each targets a different document type.

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?

The description indicates when to use the tool (after an invoice) and mentions that dunnings are created in draft mode and don't need finalization. It does not explicitly state when not to use it, but the sibling list provides enough context to differentiate. The endpoint reference adds practical guidance.

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

lexware_pursue_invoicePursue to an InvoiceA

Create a new invoice as a follow-up to a preceding sales voucher (quotation, order confirmation, or delivery note). Maps to the documented POST /invoices?precedingSalesVoucherId={id}[&finalize=true] endpoint. Set finalize=true to immediately finalize the new invoice (status "open"); omit or false to create as draft.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Invoice JSON body. Same shape as lexware_create_invoice. Required fields: voucherDate, address, lineItems, totalPrice, taxConditions. See Lexware API docs for full schema.
`finalize`	No	When true, creates the invoice in finalized "open" status. When false or omitted, creates as draft. Maps to the documented ?finalize=true query parameter.
`precedingSalesVoucherId`	Yes	UUID of the preceding sales voucher (quotation, order confirmation, or delivery note) that this invoice is pursued from.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate it's a write operation (readOnlyHint=false) and non-destructive. The description adds the endpoint mapping and finalize behavior, providing useful context beyond 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?

The description is three well-structured sentences with no fluff. It front-loads the purpose, then maps to the API endpoint, then clarifies the finalize flag.

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?

The description covers purpose, endpoint, and key behavior. It lacks return value description (no output schema) and prerequisites, but for a creation tool with sibling context, it's sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100%, and the description adds some context (e.g., relationship to preceding voucher, same shape as lexware_create_invoice for body). However, the body parameter lacks detailed field explanations, relying on external docs.

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?

The description clearly states it creates a new invoice as a follow-up to a preceding sales voucher (quotation, order confirmation, or delivery note), distinguishing it from other create tools like lexware_create_invoice.

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?

The description explains that this tool is used to create an invoice from a preceding voucher and mentions the finalize parameter behavior. While it doesn't explicitly state when not to use it, the context is clear.

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

lexware_pursue_order_confirmationPursue to an Order ConfirmationA

Create a new order confirmation as a follow-up to a preceding quotation. Maps to the documented POST /order-confirmations?precedingSalesVoucherId={id} endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	Order confirmation JSON body. Same shape as lexware_create_order_confirmation. See Lexware API docs for full schema.
`precedingSalesVoucherId`	Yes	UUID of the preceding quotation that this order confirmation is pursued from.

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=false (mutates) and destructiveHint=false. The description adds that it creates a new entity and references a preceding voucher, which is consistent. No additional side effects or behavioral nuances are disclosed.

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?

The description is two sentences, front-loaded with the core action and purpose, and contains no redundant information. Every sentence adds meaningful context.

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 creation tool without an output schema, the description adequately covers input parameters and the relationship to preceding vouchers. It could mention return value expectations, but the lack is acceptable as the tool's primary purpose is mutation.

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 parameters have descriptions. The body parameter description adds value by referencing the sibling tool lexware_create_order_confirmation and directing to Lexware API docs for full schema, which helps the agent understand the expected structure.

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?

The description clearly states the tool creates an order confirmation as a follow-up to a quotation, and maps to a specific endpoint. This distinguishes it from siblings like lexware_create_order_confirmation which creates a standalone order confirmation.

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?

The description indicates the tool is for creating order confirmations from preceding quotations, providing clear context. It does not explicitly state when not to use or mention alternatives, but the sibling lexware_create_order_confirmation is implied for standalone creation.

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

lexware_update_articleUpdate ArticleA

Idempotent

Update an existing article. The body must include the version field for optimistic locking.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Article ID
`body`	Yes	Article JSON with version field included for optimistic locking. Key fields: title, type, unitName, unitPrice, description, version (required)

TDQS

A3.7/5.0

Behavior4/5

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

The description adds behavioral context about optimistic locking via the version field requirement, which goes beyond the annotations. Annotations already indicate idempotentHint=true (safe for retries) and non-destructive, and the description aligns with these, providing additional useful detail about locking.

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?

The description is two short, front-loaded sentences with no unnecessary words. Every sentence adds value: the first states the core action, the second adds a critical requirement. Perfect conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no additional context about return values, error handling, or prerequisites (e.g., article must exist), the description is minimally adequate but lacks completeness for a mutating operation. It covers the key locking requirement but omits other behavioral details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

The input schema already provides a description for both parameters (id and body), including that the body must contain version. The description reinforces this but adds no new semantic meaning beyond the schema, so baseline score of 3 is appropriate.

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?

The description clearly states the action 'Update an existing article' with a specific resource. It distinguishes the tool from sibling tools like lexware_create_article, lexware_delete_article, and lexware_get_article.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that the body must include the version field for optimistic locking, but it provides no guidance on when to use this tool versus alternatives like create or delete, nor does it specify prerequisites or contexts where this tool is appropriate.

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

lexware_update_contactUpdate ContactA

Idempotent

Update an existing contact. The body must include the version field for optimistic locking.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Contact ID
`body`	Yes	Contact JSON with version field. Same structure as create.

TDQS

A4.2/5.0

Behavior4/5

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

The description adds behavioral context beyond annotations by specifying optimistic locking via a version field. Annotations indicate idempotentHint=true, which aligns with updates. There is no contradiction; the description reinforces the non-readOnly nature and provides safety semantics.

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?

The description is extremely concise: two sentences covering the action and a critical requirement. It is front-loaded with the verb and resource, making it efficient for agent scanning.

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 an update tool with two required parameters and no output schema, the description is largely complete. It explains the version field necessity. However, it could mention that the contact must exist before updating, but this is implicit from 'existing contact'. Overall, sufficient given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with descriptions for both parameters (id and body). The description repeats that the body must include the version field, which is already in the schema description 'Contact JSON with version field'. It does not add significant new parameter-level meaning beyond the schema.

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?

The description clearly states the action 'Update' on the resource 'existing contact'. It distinguishes from sibling tools like lexware_create_contact, lexware_get_contact, lexware_delete_contact, etc., by specifying the update operation and mentioning the version field for optimistic locking.

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?

The description explicitly requires the body to include a version field for optimistic locking, providing specific usage guidance. However, it does not contrast with alternatives (e.g., when to update vs. create) or mention prerequisites like the contact must exist. Still, the context is clear enough for most agents.

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

lexware_update_voucherUpdate VoucherA

Idempotent

Update an existing bookkeeping voucher in Lexware. Requires version field for optimistic locking.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Voucher UUID
`body`	Yes	Voucher JSON with version field for optimistic locking

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already cover idempotency and non-destructive nature; the description adds context about optimistic locking but lacks details on conflict handling or validation.

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?

The description is a single concise sentence with a clear note, front-loaded and without redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description does not explain the response format, success/failure behavior, or provide sufficient detail about the body object's structure beyond the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with descriptions for both parameters; the description reiterates the version field requirement without adding new meaning beyond the schema.

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?

The description clearly states the action (update) and the resource (existing bookkeeping voucher), distinguishing it from siblings like lexware_create_voucher.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions the requirement of a version field for optimistic locking, but does not explicitly detail when to use this tool versus alternatives or provide exclusions.

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

lexware_upload_fileUpload FileA

Upload a file to Lexware. Provide either filePath (absolute path on the MCP server host) or contentBase64 (base64-encoded content) — not both. When using filePath, fileName is optional (derived from the file name) and contentType is auto-detected for common image extensions. When using contentBase64, fileName is required.

ParametersJSON Schema

Name	Required	Description
`fileName`	No	File name for the upload. Required when using contentBase64; derived from filePath when omitted.
`filePath`	No	Absolute path to the file on the MCP server host. Must be readable by the MCP server process.
`contentType`	No	MIME type, defaults to application/pdf
`contentBase64`	No	Base64-encoded file content. Required when filePath is not provided.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which already signal a non-read, non-destructive, non-idempotent operation. The description adds context about file path accessibility ('Must be readable by the MCP server process') and the mutual exclusivity constraint, which goes beyond annotations. However, it doesn't disclose potential side effects like overwriting existing files or size limits, but given the annotations cover the basic safety profile, this is adequate.

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?

The description is concise and well-structured, with two sentences that front-load the core purpose and then detail the parameter usage. Every sentence adds value, and there is no redundancy or fluff.

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?

Given the tool's moderate complexity (4 parameters, no output schema, no nested objects), the description is complete enough. It covers the key usage scenarios and constraints. The lack of output schema means the description doesn't need to explain return values, and the annotations provide the safety profile. Minor gaps like file size limits or error handling are not critical for a basic upload tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds value by explaining the relationship between parameters (mutual exclusivity, fileName derivation, contentType auto-detection), which is not fully captured in the schema. However, since the schema already provides detailed descriptions, the incremental value is moderate, warranting a baseline 3.

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?

The description clearly states the tool's purpose: 'Upload a file to Lexware.' It specifies the two mutually exclusive input methods (filePath or contentBase64) and distinguishes it from sibling tools like lexware_download_file and lexware_upload_voucher_file by focusing on generic file upload.

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?

The description provides explicit usage guidance: it explains when to use filePath vs contentBase64, notes that fileName is optional with filePath but required with contentBase64, and mentions auto-detection of contentType for common image extensions. It also implicitly distinguishes from lexware_upload_voucher_file by focusing on generic file upload.

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

lexware_upload_voucher_fileUpload Voucher FileA

Upload a file attachment to a bookkeeping voucher. Provide either filePath (absolute path on the MCP server host) or contentBase64 (base64-encoded content) — not both. When using filePath, fileName is optional (derived from the file name) and contentType is auto-detected for common image extensions. When using contentBase64, fileName is required.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Voucher UUID
`fileName`	No	File name for the upload. Required when using contentBase64; derived from filePath when omitted.
`filePath`	No	Absolute path to the file on the MCP server host. Must be readable by the MCP server process.
`contentType`	No	MIME type, defaults to application/pdf
`contentBase64`	No	Base64-encoded file content. Required when filePath is not provided.

TDQS

A4.3/5.0

Behavior3/5

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

Beyond the annotations, the description discloses practical behaviors: fileName derivation from filePath, contentType auto-detection for common image extensions, and mutual exclusivity of filePath/contentBase64. However, it does not mention what happens on success, upload side effects, or required MCP server permissions, leaving the annotation's openWorldHint unaddressed.

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?

The description is three sentences long, front-loaded with the primary purpose, and every sentence adds needed information. There is no redundant or filler content; it is compact and structured for quick reading.

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?

Given the moderate complexity of the input (5 parameters with combinations) and no output schema, the description covers parameter selection and mutual exclusion comprehensively. It does not describe the return value or error scenarios, but for file upload tool this is a acceptable gap given the input-focused nature of the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Although the schema already covers all parameters (100% coverage), the description adds crucial inter-parameter semantics: the mutual exclusion of filePath and contentBase64, the condition requiring fileName, and the auto-detection behavior for contentType. This goes well beyond the baseline schema descriptions and is essential for correct invocation.

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?

The description uses a specific verb and resource: 'Upload a file attachment to a bookkeeping voucher.' This clearly identifies the tool's function and distinguishes it from the sibling lexware_upload_file, which is a generic upload tool. The title and description align perfectly.

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?

The description provides clear, actionable guidance on when to use filePath versus contentBase64, including the 'not both' constraint and when fileName is required. It does not explicitly compare this tool to sibling alternatives like lexware_upload_file, but the voucher-specific context makes the intended use obvious.

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

lexware_verify_webhook_signatureVerify Webhook SignatureA

Read-onlyIdempotent

Verify a Lexware webhook X-Lxo-Signature (RSA-SHA512, base64) against the raw request body. Pass the EXACT raw HTTP body bytes you received — do not JSON.parse/stringify round-trip, as Lexware signs the compact JSON as transmitted (whitespace and key order matter). On first call the public key is fetched once from developers.lexware.io and cached for the process lifetime; set LEXWARE_WEBHOOK_PUBLIC_KEY (PEM) to override (recommended for production where you cannot tolerate one-time TLS-substitution risk on the public-key fetch).

ParametersJSON Schema

Name	Required	Description	Default
`payload`	Yes	Raw HTTP request body received from Lexware (verbatim, untransformed).
`signature`	Yes	Value of the X-Lxo-Signature header (base64).

TDQS

A4.3/5.0

Behavior5/5

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

Discloses public key fetch-on-first-call caching behavior and env var override, adding value beyond annotations (readOnlyHint, idempotentHint). No contradiction with 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?

Two sentences: first explains purpose, second provides critical usage guidance. Every sentence earns its place; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks description of return value (e.g., boolean, object). With no output schema, the agent must infer behavior. Sufficient for basic usage but incomplete for advanced handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% and description reinforces schema descriptions without adding significant new constraints. Baseline 3 is appropriate.

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?

Clearly states 'Verify a Lexware webhook X-Lxo-Signature' with specific algorithm (RSA-SHA512, base64). Distinct from all sibling tools which deal with CRUD operations on articles, contacts, invoices, etc.

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?

Explicitly instructs to pass exact raw HTTP body bytes and warns against JSON round-tripping. Also explains caching and production override. No exclusions needed as no sibling provides alternative verification.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv5.2.0Aug 21, 2026

Changedlexware_list_voucherlist3 fields changed

addedInput schema / properties / contactName

Added value: +{
+  "description": "Wildcard filter on contactName, applied client-side after fetching. % = any sequence, _ = exactly one character. Case-insensitive. Example: \"Müller%\". Implies fetchAllPages.",
+  "type": "string"
+}

addedInput schema / properties / fetchAllPages

Added value: +{
+  "default": false,
+  "description": "When true, follow pagination until every page is retrieved (capped at 100 requests) instead of returning a single page.",
+  "type": "boolean"
+}

addedInput schema / properties / hasOpenAmount

Added value: +{
+  "description": "When true, keep only entries with openAmount > 0. Applied client-side after fetching. Implies fetchAllPages.",
+  "type": "boolean"
+}

Changedlexware_list_vouchers2 fields changed

changedInput schema / properties / voucherNumber / description

Previous value: -"Filter by voucher number"New value: +"Voucher number to look up. REQUIRED — the API returns 400 without it."

addedInput schema / required
```
Added value: +[
+  "voucherNumber"
+]
```

Changedlexware_upload_file4 fields changed

changedInput schema / properties / contentBase64 / description

Previous value: -"Base64-encoded file content"New value: +"Base64-encoded file content. Required when filePath is not provided."

changedInput schema / properties / fileName / description

Previous value: -"Name of the file to upload"New value: +"File name for the upload. Required when using contentBase64; derived from filePath when omitted."

addedInput schema / properties / filePath

Added value: +{
+  "description": "Absolute path to the file on the MCP server host. Must be readable by the MCP server process.",
+  "type": "string"
+}

removedInput schema / required

Removed value: -[
-  "fileName",
-  "contentBase64"
-]

Changedlexware_upload_voucher_file4 fields changed

changedInput schema / properties / contentBase64 / description

Previous value: -"Base64-encoded file content"New value: +"Base64-encoded file content. Required when filePath is not provided."

changedInput schema / properties / fileName / description

Previous value: -"Name of the file to upload"New value: +"File name for the upload. Required when using contentBase64; derived from filePath when omitted."

addedInput schema / properties / filePath

Added value: +{
+  "description": "Absolute path to the file on the MCP server host. Must be readable by the MCP server process.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "id",
-  "fileName",
-  "contentBase64"
-]New value: +[
+  "id"
+]

13 tool updatesv5.0.0Jul 27, 2026

Removedlexware_create_dunning
Addedlexware_deeplink_file
Addedlexware_deeplink_recurring_template
Addedlexware_deeplink_voucher

Changedlexware_download_credit_note_file1 field changed

addedInput schema / properties / format

Added value: +{
+  "default": "pdf",
+  "description": "Representation to request: \"pdf\" (default) or \"xml\" for the XRechnung XML e-invoice when available.",
+  "enum": [
+    "pdf",
+    "xml"
+  ],
+  "type": "string"
+}

Changedlexware_download_down_payment_invoice_file1 field changed

addedInput schema / properties / format

Added value: +{
+  "default": "pdf",
+  "description": "Representation to request: \"pdf\" (default) or \"xml\" for the XRechnung XML e-invoice when available.",
+  "enum": [
+    "pdf",
+    "xml"
+  ],
+  "type": "string"
+}

Changedlexware_download_invoice_file1 field changed

addedInput schema / properties / format

Added value: +{
+  "default": "pdf",
+  "description": "Representation to request: \"pdf\" (default) or \"xml\" for the XRechnung XML e-invoice when available.",
+  "enum": [
+    "pdf",
+    "xml"
+  ],
+  "type": "string"
+}

Changedlexware_list_contacts1 field changed

removedInput schema / properties / archived

Removed value: -{
-  "description": "Filter by archived status",
-  "type": "boolean"
-}

Changedlexware_list_voucherlist4 fields changed

addedInput schema / properties / voucherStatus / default
```
Added value: +"any"
```

changedInput schema / properties / voucherStatus / description

Previous value: -"Voucher status(es), comma-separated or \"any\". Values: draft, open, overdue, paid, paidoff, voided, accepted, rejected, unchecked"New value: +"Voucher status(es), comma-separated, or \"any\" for no status filter (default). Values: draft, open, overdue, paid, paidoff, voided, accepted, rejected, unchecked"

addedInput schema / properties / voucherType / default
```
Added value: +"any"
```

changedInput schema / properties / voucherType / description

Previous value: -"Voucher type(s), comma-separated or \"any\". Values: invoice, creditnote, orderconfirmation, quotation, deliverynote, downpaymentinvoice, dunning, purchaseinvoice, purchasecreditnote"New value: +"Voucher type(s), comma-separated, or \"any\" for no type filter (default). Values: invoice, creditnote, orderconfirmation, quotation, deliverynote, downpaymentinvoice, dunning, purchaseinvoice, purchasecreditnote"

Changedlexware_list_vouchers1 field changed

removedInput schema / properties / voucherStatus

Removed value: -{
-  "description": "Filter by voucher status",
-  "type": "string"
-}

Changedlexware_pursue_dunning1 field changed

changedInput schema / properties / body / description

Previous value: -"Dunning JSON body. Same shape as lexware_create_dunning. See Lexware API docs for full schema."New value: +"Dunning JSON body. Key fields: voucherDate, address (object with contactId or manual fields), lineItems (array), totalPrice (object), taxConditions (object). See Lexware API docs for full schema."

Changedlexware_upload_file1 field changed

addedInput schema / properties / contentType / pattern

Added value: +"^[A-Za-z0-9!#$%&'*+.^_`|~-]+\\/[A-Za-z0-9!#$%&'*+.^_`|~-]+(;[\\x20-\\x7E]*)?$"

Changedlexware_upload_voucher_file1 field changed
- addedInput schema / properties / contentType / pattern
```
Added value: +"^[A-Za-z0-9!#$%&'*+.^_`|~-]+\\/[A-Za-z0-9!#$%&'*+.^_`|~-]+(;[\\x20-\\x7E]*)?$"
```

64 tool updatesv3.0.0May 26, 2026
- First observedlexware_create_article
- First observedlexware_create_contact
- First observedlexware_create_credit_note
- First observedlexware_create_delivery_note
- First observedlexware_create_dunning
- First observedlexware_create_event_subscription
- First observedlexware_create_invoice
- First observedlexware_create_order_confirmation
- First observedlexware_create_quotation
- First observedlexware_create_voucher
- First observedlexware_deeplink_contact
- First observedlexware_deeplink_credit_note
- First observedlexware_deeplink_delivery_note
- First observedlexware_deeplink_down_payment_invoice
- First observedlexware_deeplink_dunning
- First observedlexware_deeplink_invoice
- First observedlexware_deeplink_order_confirmation
- First observedlexware_deeplink_quotation
- First observedlexware_delete_article
- First observedlexware_delete_event_subscription
- First observedlexware_download_credit_note_file
- First observedlexware_download_delivery_note_file
- First observedlexware_download_down_payment_invoice_file
- First observedlexware_download_dunning_file
- First observedlexware_download_file
- First observedlexware_download_invoice_file
- First observedlexware_download_order_confirmation_file
- First observedlexware_download_quotation_file
- First observedlexware_get_article
- First observedlexware_get_contact
- First observedlexware_get_credit_note
- First observedlexware_get_delivery_note
- First observedlexware_get_down_payment_invoice
- First observedlexware_get_dunning
- First observedlexware_get_event_subscription
- First observedlexware_get_file_status
- First observedlexware_get_invoice
- First observedlexware_get_order_confirmation
- First observedlexware_get_payments
- First observedlexware_get_profile
- First observedlexware_get_quotation
- First observedlexware_get_recurring_template
- First observedlexware_get_voucher
- First observedlexware_list_articles
- First observedlexware_list_contacts
- First observedlexware_list_countries
- First observedlexware_list_event_subscriptions
- First observedlexware_list_payment_conditions
- First observedlexware_list_posting_categories
- First observedlexware_list_print_layouts
- First observedlexware_list_recurring_templates
- First observedlexware_list_voucherlist
- First observedlexware_list_vouchers
- First observedlexware_pursue_credit_note
- First observedlexware_pursue_delivery_note
- First observedlexware_pursue_dunning
- First observedlexware_pursue_invoice
- First observedlexware_pursue_order_confirmation
- First observedlexware_update_article
- First observedlexware_update_contact
- First observedlexware_update_voucher
- First observedlexware_upload_file
- First observedlexware_upload_voucher_file
- First observedlexware_verify_webhook_signature

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Disambiguation4/5

Most tools are clearly distinguished by resource and action, but a few pairs like lexware_list_vouchers vs. lexware_list_voucherlist and lexware_download_file vs. lexware_download_invoice_file could confuse agents without careful description reading.

Naming Consistency5/5

All 66 tools follow a consistent 'lexware_<verb>_<resource>' pattern, using uniform verbs such as get, create, update, delete, list, download, upload, pursue, deeplink, and verify. No mixing of conventions.

Tool Count1/5

With 66 tools, this far exceeds the 50+ threshold for extreme mismatch. Even for a broad ERP integration, the sheer number is overwhelming and could be consolidated (e.g., combining reference data list endpoints or clarifying voucher list variants).

Completeness4/5

Core document workflows (create, retrieve, download, deeplink, pursue) are well covered across sales documents, and articles/contacts have full CRUD. Minor gaps include no create for down payment invoices and no update/delete for most sales documents, which may reflect API limitations.

Maintenance

ActivityMaintained

ResponsivenessSlow

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.pdfgate
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
Documentation Access File Systems
1
Mini AccountantOAuth
app.miniaccountant
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
E-commerce & Retail Finance ERP Systems
1
codat A
io.usefulapi
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Finance ERP Systems Data Platforms
282
lacita A
app.lacita.api
MCP server for lacita - appointment management software
App Automation Customer Support Project Management
282

Related MCP Servers

buchpilot-mcp
Finance App Automation ERP Systems
makririch
F
license
B
quality
D
maintenance
MCP server for DACH accounting automation. Connect AI assistants to sevDesk and Lexoffice — create invoices, manage contacts, handle bookings and vouchers for German-speaking businesses.
Updated 5 months ago (2026-04-13 14:55 UTC)
15
56
-
Lexware Office MCP Server
Finance ERP Systems
bdiaby1
A
license
A
quality
B
maintenance
Enables MCP-capable assistants to query and manage Lexware Office contacts, sales documents, vouchers, files, payments, webhooks, and reference data via the Lexware Office public API. Adds bank reconciliation tools for matching bank statement CSVs against Lexware vouchers or scanned receipt PDFs.
Updated a month ago (2026-08-03 10:06 UTC)
4
MIT
Lexware Office MCP Server
Finance ERP Systems
bdiaby1
A
license
A
quality
B
maintenance
MCP server for Lexware Office that enables querying and managing contacts, sales documents, vouchers, files, payments, and webhooks through a sandboxed two-tool interface (search/execute) with read-only-by-default write safety.
Updated 15 days ago (2026-08-23 14:22 UTC)
2
MIT
easybill-mcp
Payments & Billing Finance ERP Systems
stack74
A
license
A
quality
C
maintenance
MCP server providing access to the easybill REST API for managing invoices, customers, articles, payments, projects, and time tracking, with read-only mode by default.
Updated a month ago (2026-08-04 14:28 UTC)
16
28
19
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lazyants/lexware-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server