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 "Deploy 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 Source Related Servers Discussions Admin

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 ArticleB

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

B3.4/5.0

Behavior3/5

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

Annotations already indicate a non-read-only, non-idempotent mutation, but the description adds no additional behavioral traits (e.g., side effects, permissions, or error handling). It 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?

The description is a single, front-loaded sentence with no unnecessary words, making it concise 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 absence of an output schema and the complexity of creating an article (with nested pricing fields), the description is too brief. It does not explain what an article is, required fields beyond the schema, or expected outcomes.

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 parameters, including a detailed description of the 'body' object. The tool description adds no extra meaning beyond what the schema provides, meriting a baseline score 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 'Create a new article' clearly specifies the verb (Create) and the resource (article), distinguishing it from sibling tools like lexware_get_article or 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?

No guidance is provided on when to use this tool versus alternatives, such as when to create an article vs. a voucher or contact. The description lacks context about prerequisites or use cases.

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

lexware_create_contactCreate ContactB

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

B3.1/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 non-destructive nature (destructiveHint=false). However, the description adds no additional behavioral context (e.g., required permissions, side effects like address validation) beyond confirming it creates a contact.

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 with no waste, though it could be slightly expanded to include key behavioral notes without sacrificing 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?

Given the lack of output schema, the description does not explain what the tool returns (e.g., created contact ID or object). This is a significant gap for a creation tool, especially when sibling tools like lexware_get_contact exist.

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 parameter descriptions, including nested fields. The tool description adds no extra semantic value beyond what the schema already provides, which meets 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?

The description 'Create a new contact.' uses a specific verb ('create') and resource ('contact'), clearly distinguishing it from sibling tools like lexware_update_contact or lexware_get_contact.

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 context on when to use this tool compared to alternatives (e.g., lexware_update_contact for updates) or any prerequisites, leaving the agent without guidance.

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.4/5.0

Behavior3/5

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

Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive. The description adds no extra behavioral context, such as idempotency or side effects, which would be helpful for a creation tool.

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 or repetition. It directly states the purpose.

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 it's a creation tool with a complex nested body and no output schema, the description is too minimal. It does not explain what a credit note is, required fields, or result expectations, leaving agents underinformed.

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 for the 'body' property, with a description listing key fields. The tool description does not add additional parameter 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 'Create a new credit note in Lexware.' It uses a specific verb (create) and resource (credit note), distinguishing it from sibling 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, prerequisites, or typical scenarios. The description lacks any context for usage.

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 NoteB

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

B3.4/5.0

Behavior3/5

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

Annotations already indicate this is a write operation (readOnlyHint=false) and not idempotent nor destructive. The description does not add any extra behavioral context such as what happens on creation, required permissions, or rate limits. It adds marginal value 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 sentence that is perfectly concise with no superfluous words. It conveys the essential purpose efficiently.

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 has a complex nested input and no output schema, the description is too minimal. It lacks details on return value, success criteria, or any important contextual information that would help an agent know what to expect. More information is needed 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?

The input schema describes the 'body' parameter with key fields, achieving 100% schema description coverage. The tool description does not provide additional semantic meaning beyond what is in 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?

The description clearly states the action ('Create') and the resource ('delivery note'), which distinguishes it from sibling tools like lexware_get_delivery_note or lexware_download_delivery_note_file. It is specific and 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?

No guidance is provided on when to use this tool versus alternatives such as lexware_create_invoice or lexware_create_credit_note. There is no mention of prerequisites, restrictions, or context for using this delivery note creation endpoint.

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 SubscriptionB

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

B3/5.0

Behavior2/5

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

Annotations already indicate this is a write operation (readOnlyHint=false) and not idempotent (idempotentHint=false). The description adds no additional behavioral context (e.g., whether duplicate creations fail, authentication requirements, 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 concise sentence that is correctly front-loaded with the action. However, it is extremely minimal and provides no structural elements like separate sections or examples.

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 no output schema, the description should explain the response or success behavior (e.g., returns the subscription ID). It also does not leverage the openWorldHint annotation to clarify that new event types may be valid. The description is incomplete for a creation 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 100% description coverage for both parameters. The description simply restates the tool purpose and does not provide additional meaning or examples 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 a specific action ('Create a new webhook event subscription') and resource ('event subscription in Lexware'). It distinguishes from sibling tools like lexware_list_event_subscriptions, 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 is provided on when to use this tool versus alternatives (e.g., listing or deleting subscriptions). The description does not mention any 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_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 non-readOnly and non-idempotent behavior. The description adds valuable context that finalization can only happen at creation time and not on existing drafts, disclosing a key behavioral constraint 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?

Two sentences with no redundancy. The critical information about finalization is front-loaded. Every word serves a purpose.

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 low parameter count and presence of annotations, the description adequately covers the tool's purpose and key behavior. It lacks return value details, but the absence of an output schema and the tool's simplicity make this acceptable.

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%, baseline 3. The description adds meaning by explaining the finalize parameter's effect and limitation, and gives examples of key fields in the body parameter, though it defers to API docs for full 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 it creates an invoice in Lexware, distinguishing between draft and finalized via the finalize parameter. The tool name and sibling context further differentiate it from other document creation tools like credit notes or quotations.

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 when to use finalize=true vs false, and notes that this is the only way to get a finalized invoice since the API doesn't support finalizing a draft later. It does not explicitly compare with sibling tools, but the tool name and context are sufficient.

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 ConfirmationB

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

B3.2/5.0

Behavior2/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral details (e.g., side effects, permissions, rate limits). It 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?

The description is a single, concise sentence with no unnecessary words, fitting the tool's simplicity.

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?

Despite having only one parameter, the description lacks information about the return value (e.g., created order confirmation ID), and the tool's complexity (nested objects) is not fully addressed.

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 description provides key fields (voucherDate, address, lineItems, etc.), but it relies on external API docs, offering moderate added value over 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 ('Create') and the resource ('order confirmation'), and it differentiates from sibling 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 is provided on when to use this tool versus alternatives (e.g., create_voucher, create_invoice), nor any 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_create_quotationCreate QuotationA

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

A3.5/5.0

Behavior3/5

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

Annotations already indicate non-readOnly, non-destructive, non-idempotent, and openWorldHint, which the description does not contradict. The description only confirms 'create' (a write operation) but adds no further behavioral context like authentication needs or side effects. With annotations providing the safety profile, the description adds minimal value but 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 a single, clear sentence with no wasted words. It front-loads the core purpose and is appropriately concise for a straightforward creation tool.

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 complexity of a single nested parameter and minimal annotations, the description is brief but sufficient when combined with the schema. However, it does not elaborate on the returned object or any constraints, and with many sibling tools, more contextual guidance would be beneficial. It meets the minimum viable level.

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 for the 'body' parameter that lists key fields. The tool description does not mention parameters. Per evaluation rules, high schema coverage sets a baseline of 3, even without param info in the description. No additional meaning is provided 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 explicitly states 'Create a new quotation in Lexware,' using a specific verb and resource. The tool name alone clearly distinguishes it from sibling tools like create_invoice or create_credit_note, which target different 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?

The description offers no guidance on when to use this tool versus alternatives (e.g., create_invoice, create_order_confirmation). It does not mention prerequisites, context, or exclusions, leaving the agent without decision support for choosing this tool.

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

lexware_create_voucherCreate VoucherA

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

A3.6/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, signaling a write operation. The description adds context by saying 'create' but provides no additional behavioral details like idempotency, validation, or side effects 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.

Conciseness4/5

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

The description is a single, efficient sentence. It front-loads the core purpose but could include more context 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?

No output schema is provided, yet the description does not explain return values. The tool has a single nested parameter and many sibling alternatives; more detail on when to create a voucher vs. invoice would improve completeness.

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 a description for body. The description lists key fields (type, voucherNumber, etc.), adding meaning beyond the schema's property 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 'Create a new bookkeeping voucher in Lexware', using a specific verb and resource. It distinguishes from sibling tools like lexware_update_voucher and lexware_list_vouchers.

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 such as lexware_create_invoice or lexware_create_credit_note. The description does not mention prerequisites or decision factors.

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

A4.1/5.0

Behavior3/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds that it returns a URL, which is useful context but does not expand significantly 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?

Single sentence, front-loaded with verb and resource, zero wasted words. Excellent conciseness.

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, rich annotations, and no output schema, the description fully captures what the tool does and returns. No 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?

Schema coverage is 100%, with 'id' parameter described as Contact ID with format. Description adds no additional parameter details, 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 returns a direct URL to view a contact in Lexware web app. Verb+resource is specific, and sibling tools for other entities make differentiation natural.

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?

Description implies use for getting a contact URL, but does not explicitly contrast with other deeplink tools or state when not to use. Context from sibling names helps, but explicit guidance is missing.

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.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, destructiveHint=false. The description adds the phrase 'view/edit', which could imply mutability, but the tool itself is read-only (returns a link). No additional behavioral traits like return format or permissions 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 a single, efficient sentence conveying the essential purpose without extra 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 tool with one parameter and comprehensive annotations, the description is sufficient. It clearly states the output (a direct link) and purpose, though it could mention that the link leads to the Lexware web app for viewing/editing.

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 parameter 'id' described as 'Credit note UUID'. The description adds no additional context beyond the schema, so 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 verb 'Get' and the resource 'direct link to view/edit a credit note', making the tool's purpose explicit. It differentiates from siblings like lexware_deeplink_voucher or CRUD tools by specifying the credit note resource.

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 obtaining a URL to a credit note, but does not explicitly state when to use this vs. alternatives like deeplink_invoice or CRUD operations. No exclusion criteria or alternative suggestions are provided.

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.7/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 'view/edit' which clarifies the link's purpose but does not disclose additional behavioral traits beyond the annotations. No contradiction found.

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 effectively communicates the tool's purpose. It is front-loaded and contains no extraneous information, though it could be slightly expanded for completeness.

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 tool with one parameter, full schema coverage, and thorough annotations, the description provides sufficient context. It explains the output (a direct link) and the tool's intent, without needing to detail return values since there is 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?

The single parameter 'id' is fully documented in the schema with a description ('Delivery note UUID') and format constraints. The description adds no further meaning beyond the schema, so a baseline score of 3 is appropriate given 100% 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 tool returns a direct link to view/edit a delivery note in the Lexware web app. It uses a specific verb ('Get') and specific resource ('direct link to view/edit a delivery note'), distinguishing it from sibling tools like lexware_get_delivery_note (returns data) or lexware_download_delivery_note_file (downloads 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 use when a deep link to a delivery note is needed, but does not explicitly state when to use this versus alternative tools such as other deeplink tools (e.g., lexware_deeplink_invoice). No exclusions or contextual guidance is provided.

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.7/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 the tool provides a 'direct link to view/edit,' which aligns with annotations. However, it does not disclose additional behavioral traits such as the output format (e.g., URL string) or any side effects like authentication requirements. With annotations covering key aspects, this is adequate but not enriched.

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 14 words that directly states purpose. It is front-loaded with key action ('Get a direct link') and resource, with no extraneous information. Every word earns its place, achieving maximum efficiency.

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 (single-parameter, no output schema, good annotations), the description is minimally adequate. It identifies what the tool does but does not describe the return value (e.g., type of link, format). For completeness, the agent would benefit from knowing the output is a string URL or the link structure. However, the annotations and schema cover input and safety, so this gap is moderate.

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 'id' with description 'Down payment invoice UUID.' The tool description adds no extra meaning beyond what the schema provides. According to guidelines, when schema coverage is high, baseline is 3, and the description does not compensate further.

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 a direct link' and identifies the specific resource ('down payment invoice') and the intended action ('view/edit'). It effectively distinguishes this tool from sibling tools like lexware_get_down_payment_invoice (which retrieves data) and lexware_download_down_payment_invoice_file (which downloads a file). The purpose is explicit and unambiguous.

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 provide explicit guidance on when to use this tool versus alternatives. While the purpose implies use for obtaining a link to the web UI, there is no mention of prerequisites, context, or exclusions (e.g., when to use lexware_get_down_payment_invoice instead). The agent must infer usage from the name and purpose, which is sufficient 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_dunningDeeplink to DunningA

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

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds that it returns a link for viewing/editing, which is consistent but doesn't provide additional behavioral details like authentication requirements or error scenarios. With annotations present, 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 a single, concise sentence of 12 words with no unnecessary information. 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 tool's simplicity (one parameter, no output schema) and the presence of annotations, the description is mostly complete. It explains the purpose and result, but could mention the format of the link or that it's read-only (though annotations cover safety).

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 doesn't add any additional meaning beyond what the schema provides for the 'id' parameter. 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 ('Get a direct link') and the resource ('a dunning'). It distinguishes from sibling tools like lexware_get_dunning (which retrieves data) and lexware_deeplink_voucher (different 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 (e.g., when to use deeplink vs. get_dunning or pursue_dunning). The agent is left to infer without explicit context.

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 InboxB

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

B3.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, and destructiveHint=false. The description adds that the tool returns a 'direct link' to the bookkeeping inbox, which is consistent. No contradictions but no additional behavioral details (e.g., auth requirements, rate limits) are provided. This is adequate given the annotation coverage.

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, efficient sentence that conveys the core purpose without excess. It is front-loaded and to the point. However, given the many siblings, slightly more detail might be warranted 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?

The tool has no output schema, so the description should hint at return value. It does mention 'direct link', which is helpful. But it does not clarify whether the link leads to viewing or uploading, or if it's for all files or only newly uploaded. In context of many similar tools, this is adequate but not fully comprehensive.

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 description coverage is 100%. According to the rubric, 0 parameters yields a baseline of 4. The description adds no parameter information since none exist, which 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 verb 'Get a direct link' and the resource 'bookkeeping inbox of newly-uploaded files', distinguishing it from other deeplink tools that target specific document types. However, the phrase 'newly-uploaded files' may imply a temporal limitation that is not confirmed, causing slight ambiguity.

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 explicit guidance on when to use this tool versus alternates. Given many sibling deeplink tools for different entities (vouchers, invoices, contacts, etc.), the lack of usage context or alternatives is a significant gap.

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.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds the ability to 'view/edit' but does not elaborate on link behavior (e.g., temporary vs. permanent, authentication required). Minimal added value 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, well-structured sentence that front-loads the action and explicitly names the resource. 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 tool with one parameter and no output schema, the description covers the core functionality. However, it omits the return format (e.g., URL string), which would improve completeness. Annotations supplement safety but not output specifics.

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 'Invoice UUID' for the parameter. The tool description adds no additional meaning or syntax guidance beyond what the schema already provides, 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 ('Get') and the resource ('direct link to view/edit an invoice'), with the specific entity ('invoice') distinguishing it 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 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., other deeplink tools or invoice retrieval tools). The description does not mention prerequisites, context, or exclusions.

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.8/5.0

Behavior3/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the link allows viewing and editing, which is consistent. However, it does not disclose details like whether authentication is required or link expiration behavior. Additional context beyond annotations is 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?

A single, clear sentence with no unnecessary words. It front-loads the purpose and is appropriately 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 deeplink tool with one parameter and no output schema, the description sufficiently explains the purpose. It does not elaborate on the link format or behavior, but that is not critical for a tool of this complexity.

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 only parameter 'id' is fully described in the schema with format and description. Schema coverage is 100%, so the description adds no further meaning. 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 tool returns a direct link to view or edit an order confirmation in the Lexware web app. It uses a specific verb ('get') and resource ('order confirmation'), and distinguishes from sibling deeplink tools by specifying the 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 Guidelines3/5

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

The description implies this tool is for obtaining a deep link, but it does not explicitly state when to use it versus alternatives like lexware_get_order_confirmation (which returns data) or other deeplink tools. No context about when not to use it is provided.

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.9/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns a 'direct link' but does not elaborate on link behavior (e.g., expiration, authentication). It 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?

The description is a single, concise sentence that directly states the tool's function. No unnecessary words, perfectly front-loaded.

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 tool's simplicity (one parameter, no output schema, safe annotations), the description is complete. It adequately informs the agent of what the tool does without needing further elaboration.

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 parameter 'id' described as 'Quotation UUID'. The description adds no additional semantic value 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?

The description clearly states the tool's purpose: 'Get a direct link to view/edit a quotation in the Lexware web app.' It uses a specific verb ('Get') and resource ('direct link to quotation'), and distinguishes it from sibling tools like 'lexware_deeplink_invoice' by focusing on quotations.

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 direct link to a quotation is needed, but it does not provide explicit guidelines on when to use this tool versus alternatives (e.g., 'lexware_get_quotation' for data). No prerequisites or when-not-to-use hints are given.

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.8/5.0

Behavior3/5

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

Annotations already indicate read-only and idempotent behavior. The description adds that it returns a direct link, 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, front-loaded sentence that efficiently 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.

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 no output schema, the description is mostly complete. It could mention the return format (e.g., URL string) but the context of sibling tools suggests this is standard.

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 description for the 'id' parameter. The description does not add meaning beyond what the schema provides, so a 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 it provides a direct link to view/edit a recurring invoice template, distinguishing it from 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?

The description implies usage for obtaining a deeplink to a recurring template, but lacks 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

Behavior4/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 adds value by specifying the output (a direct link) and the dual view/edit capability. This context 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 a single 13-word sentence with no filler. It is front-loaded with the verb and resource, and every word contributes meaning. It is maximally concise.

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 tool's low complexity (1 parameter, no output schema, clear annotations), the description is complete. It explains what the tool returns (a link) and its purpose, which is sufficient for an agent to use it 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 voucherId, which already has a clear description. The tool description does not add any extra meaning or usage details beyond the schema, so it meets but does not exceed the baseline.

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 resource 'direct link to view/edit a bookkeeping voucher', precisely indicating the tool's purpose. It distinguishes itself from siblings like lexware_get_voucher (which retrieves voucher data) and other deeplink tools.

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?

While the description implies usage (for obtaining a deeplink), it does not explicitly state when to use this tool versus alternatives like lexware_get_voucher or other deeplink tools. No 'when-not' or alternative guidance is provided.

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.4/5.0

Behavior3/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't contradict. However, it adds no additional behavioral context (e.g., irreversibility, side effects) 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.

Conciseness4/5

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

Very short and to the point, with no wasted words. Could be slightly more structured but remains efficient.

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 delete operation, the description is minimally adequate but lacks details on consequences (e.g., if deletion is permanent). Annotations partially compensate, but 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?

Schema has 100% coverage, including format and pattern for 'id'. The description merely mentions 'by ID', adding 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 'Delete an article by ID' clearly states the action (delete) and resource (article), distinguishing it from sibling tools like get, create, update.

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, no prerequisites or conditions mentioned. 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_delete_event_subscriptionDelete Event SubscriptionB

Destructive

Delete a webhook event subscription from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Event subscription UUID

TDQS

B3.3/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, and the description adds no additional behavioral context (e.g., side effects, reversibility, 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?

Single sentence with no superfluous information; front-loaded and efficient.

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 delete tool with one parameter and no output schema, the description is adequate but lacks usage context and behavioral nuance that could aid 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?

Schema coverage is 100% with a description for the 'id' parameter; the tool description adds no extra meaning beyond that, meeting the baseline.

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 states a specific verb ('Delete') and resource ('webhook event subscription'), clearly distinguishing from sibling tools like create, get, list, and verify.

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., when to delete vs. list or create), nor any prerequisites like requiring the subscription ID from listing.

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.4/5.0

Behavior4/5

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it defaults to PDF, and if XML is requested but unavailable, the API returns whatever representation it can render. This explains fallback behavior 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 highly concise with two sentences. The first sentence states the core action, and the second sentence adds critical format details. No extraneous information; 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?

Given the tool's simplicity (2 params, no output schema) and annotations covering safety/idempotency, the description adequately explains the key behavior (format fallback). It could mention what the tool returns (e.g., file blob) but the absence is not critical since the sibling tools and API pattern imply a file download.

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 input schema provides 100% coverage with descriptions for both parameters. The description adds meaning by explaining the purpose of the 'format' parameter (XRechnung XML e-invoice) and its behavior when the requested format is not available. This enriches the schema descriptions.

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

Purpose5/5

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

The description clearly states the action ('Download the file for a credit note') and specifies the resource (credit note). It distinguishes from sibling tools like download_invoice_file by focusing on credit notes specifically. The format options (PDF default, XML for XRechnung) are explicitly mentioned.

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 when to use this tool (to download a credit note file) and provides context for the format parameter (when to request XML). It could be improved by explicitly stating when not to use it or mentioning alternatives like download_invoice_file, but the sibling context and the description itself make the intended use clear.

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 FileA

Read-onlyIdempotent

Download the PDF file for a delivery note.

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 declare readOnlyHint, idempotentHint, and openWorldHint. The description does not contradict these and adds no extra behavioral information. 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, clear sentence with no wasted words. It is well-structured and front-loaded.

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 tool's simplicity (one parameter, no output schema) and rich annotations, the description is complete enough to enable correct usage.

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 single 'id' parameter has a description 'Delivery note UUID'). The description adds no new parameter information 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 tool downloads a PDF file for a delivery note. It uses a specific verb and resource, and distinguishes it from sibling download tools by specifying '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 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, such as needing a delivery note ID first or using get_delivery_note to retrieve metadata.

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 read-only, idempotent, non-destructive. Description adds that API returns 'whatever representation it can render' when requesting XML, a useful behavioral detail 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, front-loaded with primary action, no redundant information. Efficient and clear.

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 rich annotations and full schema coverage, description adequately covers purpose and format behavior. Minor gap: does not explicitly state fallback behavior when XML unavailable, but 'whatever it can render' implies it.

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 covers 100% of parameters with descriptions. Description adds value by explaining default and conditional availability of XML format, enhancing understanding beyond bare 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?

Description clearly states 'Download the file for a down payment invoice' with verb and specific resource, distinguishing it from sibling download 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 Guidelines4/5

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

Provides guidance on format parameter (default PDF, optional XML for XRechnung) but does not explicitly differentiate from similar download tools beyond the resource name.

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.9/5.0

Behavior3/5

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

Annotations already indicate readOnly, non-destructive, idempotent hints, so the description's statement 'Download the PDF file' aligns without adding new behavioral insights. It does not contradict annotations but adds no extra context (e.g., file size limits, authentication needs).

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 that directly states the tool's purpose with no wasted words. It is optimally concise for such a simple operation.

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 tool's low complexity (one parameter, no output schema) and the presence of comprehensive annotations, the minimal description is complete. It conveys all necessary information 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 coverage is 100% with a single 'id' parameter described as 'Dunning UUID' and format. The description adds no extra meaning beyond what the schema provides, 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 verb 'Download' and the resource 'PDF file for a dunning', which is specific and distinct from sibling tools like lexware_download_invoice_file. It unambiguously identifies the tool's function.

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 use when a dunning PDF is needed, but provides no explicit guidance on when to use this tool versus alternatives, nor prerequisites or exclusions. Context signals indicate a simple tool, but no usage best practices are given.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful but minimal context: the response format (base64). It does not disclose potential errors, size limits, or behavior for invalid IDs, so it is adequate but not exceptional.

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 consists of two concise sentences with no wasted words. It is front-loaded with the core action and immediately specifies the return format. Every sentence adds essential 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?

Given the tool's simplicity (one required parameter, no output schema), the description is largely sufficient. It conveys the basic function and output format. However, it could be more complete by mentioning error conditions, file size limits, or the relationship to other download tools. The annotations fill in many gaps, so a 4 is appropriate.

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 for the single parameter 'id', described as 'File UUID' with a UUID pattern. The description does not add additional semantic meaning beyond what the schema provides, such as how to obtain the ID or constraints on file types. The baseline score of 3 applies given the high schema 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 'download' and resource 'file from Lexware', and specifies the return format as base64-encoded content. However, it does not differentiate from numerous sibling download tools for specific document types (e.g., invoices, credit notes), leaving ambiguity about when to use this generic file download versus a specialized one.

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 like lexware_download_invoice_file or lexware_download_credit_note_file. The description fails to clarify context, prerequisites, or exclusions, which is a significant gap given the many sibling tools.

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.3/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive. The description adds the behavioral nuance that the API returns whatever representation it can render, indicating potential fallback if the requested format is unavailable. This adds value 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, minimal and front-loaded. The first sentence gives the core action, and the second explains the optional format. 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?

For a simple download tool with two parameters and no output schema, the description covers the key behaviors (default format, optional XML, availability caveat). The context is complete for agent decision-making, especially given the strong annotation support.

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 has 100% coverage, so baseline is 3. The description adds context for the format parameter, explaining that XML requests the XRechnung e-invoice and that availability varies. For the id parameter, it repeats the schema's description but provides no additional meaning. Overall, the description enriches the format parameter sufficiently.

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 downloads invoice files, specifies default PDF and optional XML format, and the tool name uniquely identifies it for invoices. It distinguishes from sibling download tools by focusing on invoices.

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 invoice file downloads but lacks explicit guidance on when to use this tool versus alternatives like lexware_download_file or other document download tools. No exclusions or alternative comparisons are provided.

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 FileA

Read-onlyIdempotent

Download the PDF file for an order confirmation.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Order confirmation 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, idempotentHint=true, destructiveHint=false, indicating a safe, idempotent read operation. The description adds no further behavioral context (e.g., what happens if the ID is invalid or file not found). It 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?

The description is a single short sentence that clearly conveys the tool's purpose. Every word earns its place, with 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?

There is no output schema. The description omits details about the return format (e.g., raw PDF binary) or potential error handling, which would be useful for an AI agent. However, for a simple download tool, the lack of extensive context is acceptable.

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 documents the single required parameter 'id' with UUID format and description 'Order confirmation UUID'. The description adds no further semantics beyond schema coverage. 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 downloads the PDF file for an order confirmation. It specifies the verb 'download' and the resource 'PDF file for an order confirmation', distinguishing it from sibling download tools for invoices, credit notes, etc.

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. There is no mention of prerequisites or exclusions. Among siblings with similar download functions, explicit guidance would help an AI agent choose correctly.

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

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, indicating safe, non-destructive behavior. The description adds no behavioral context beyond the structured data, which is adequate but not enriched.

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, no wasted words, front-loaded with key verb and noun.

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 with no output schema, the description is nearly complete. However, it omits what to expect (e.g., binary file download) and not just metadata.

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 schema already describes the 'id' parameter as Quotation UUID. The description adds no further meaning, meeting the baseline.

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), the resource (PDF file for a quotation), and matches the tool's name, distinguishing it 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 Guidelines4/5

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

The description implies use for quotation PDFs; sibling tools clarify alternatives for other document types, but no explicit when-not-to-use or prerequisites are provided.

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?

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds no additional behavioral context, 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?

A single, clear sentence with no unnecessary words. It is front-loaded and efficiently conveys the tool's purpose.

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 simple (1 required parameter, no output schema, rich annotations), the description is mostly complete. It could mention that the response contains the full article object, but the lack of output schema and simplicity mitigate this 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?

Schema coverage is 100% and the single parameter 'id' has a description 'Article ID' in the schema. The description adds no further 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?

Clearly states the verb 'Get', resource 'single article', and method 'by ID'. This distinguishes it from sibling tools like lexware_list_articles which retrieves multiple articles.

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 when-to-use or when-not-to-use guidance. While a simple tool, it could mention that this should be used when you have a specific article ID, versus listing or searching.

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?

Description does not add behavioral insight beyond annotations. Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds no extra context about side effects or requirements.

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?

Description is a single, clear sentence with no superfluous words. Front-loaded with essential information. Appropriate for the tool's simplicity.

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 simple retrieval operation, one parameter, zero output schema, and comprehensive annotations, the description is complete. No further context is needed.

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?

Only one parameter (id) with schema description 'Contact ID'. Description mentions 'by ID' but adds no semantic detail beyond what the schema already provides. Schema coverage is 100%, so baseline 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 'Get a single contact by ID', specifying verb (get), resource (contact), and parameter (ID). This distinguishes it from sibling tools like lexware_list_contacts (list) and lexware_create_contact (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?

No explicit guidance on when to use this tool versus alternatives, but the simple nature of fetching by ID implies usage. It does not mention when not to use or provide alternative tool names.

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

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds 'retrieve' which aligns. No additional behavioral context (e.g., auth, error handling) is provided, but 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 sentence with no wasted words. It efficiently conveys the tool's 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?

For a simple get-by-ID tool with full schema coverage and comprehensive annotations, the description is complete. No output schema is provided but is not needed for this straightforward operation.

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 parameter 'id' described as 'Credit note UUID'. The description adds no extra meaning beyond 'by ID', so 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 the action (retrieve), the resource (credit note), and the identifier (by ID). It distinguishes from sibling tools like lexware_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 Guidelines4/5

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

The description implies usage when a credit note ID is known, but does not explicitly mention when not to use it or suggest alternatives like other retrieval tools.

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 provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description simply restates 'Retrieve' which is consistent but adds no new behavioral context. It 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, no wasted words, front-loaded with the verb and resource. 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 retrieval tool with one parameter, full schema coverage, and rich annotations, the description is fully adequate. No additional context is necessary.

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 single parameter 'id' described as 'Delivery note UUID'. 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 clearly states the action (Retrieve) and the resource (delivery note by ID from Lexware). It distinguishes itself from sibling tools like get_article, get_invoice, etc. by specifying the resource type.

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 such as create_delivery_note, download_delivery_note_file, or pursue_delivery_note. The description does not mention 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_down_payment_invoiceGet Down Payment InvoiceB

Read-onlyIdempotent

Retrieve a down payment invoice by ID from Lexware.

ParametersJSON Schema

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

TDQS

B3.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, and no destructiveHint. The description adds no additional behavioral context (e.g., rate limits, restrictions, or output details). It merely restates the purpose, so it contributes minimal value 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, clear sentence with no unnecessary words. It is perfectly sized for the simple operation.

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 one parameter, strong annotations, and no output schema, the description functionally communicates what the tool does. However, it lacks any details about the return value (e.g., what fields are in a down payment invoice), which would be helpful for an agent. Still adequate for 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 a clear parameter description ('Down payment invoice UUID'). The tool description mentions 'by ID' but does not add any new meaning or usage hints 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.

Purpose4/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 resource (down payment invoice by ID). It effectively distinguishes from sibling tools like get_invoice or get_credit_note by specifying the resource type. However, it does not add detail beyond the tool name, which slightly limits its value.

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., other get tools or download/deeplink tools for down payment invoices). No when-not-to-use or alternative tool names are mentioned.

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.5/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context beyond what the annotations and schema offer, but 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?

One concise sentence that is front-loaded and contains no extraneous information. Every word is necessary.

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 read operation with well-annotated safety, the description is sufficient but lacks explanation of the return value (no output schema) or what a dunning is. Could provide more context, but not severely deficient.

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 the 'id' parameter described as 'Dunning UUID'. The description repeats the parameter role but adds no further detail, 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 the verb 'Retrieve' and resource 'a dunning by ID from Lexware'. It distinguishes itself from sibling tools like lexware_pursue_dunning, lexware_download_dunning_file, and lexware_deeplink_dunning, which have different actions.

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., lexware_pursue_dunning). The description does not mention context or exclusions, leaving the agent to infer usage.

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

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 covered. The description adds no additional behavioral context beyond the basic retrieval action.

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, focused sentence with no redundancy, front-loading the key 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?

Given the single parameter, rich schema, and comprehensive annotations, the description adequately covers the tool's purpose without needing additional detail.

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 'id' parameter is well-defined with format, pattern, and description. The description does not add extra 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 action 'Retrieve' and the resource 'webhook event subscription by ID', distinguishing it from sibling tools like lexware_list_event_subscriptions and lexware_create_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 Guidelines4/5

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

The context is clear: use when you have a specific subscription ID and want its details. However, no explicit guidance on when not to use or alternatives 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_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.5/5.0

Behavior2/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no additional behavioral context such as rate limits, permissions, or what happens if the ID does not exist. With annotations covering safety, the description does not go beyond 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?

One sentence, no wasted words. The tool's purpose is immediately clear.

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 get operation with one parameter and no output schema, the description is minimally adequate. However, it does not describe the return format or any edge cases, which would be helpful for correctness.

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 parameter 'id' described as 'Invoice UUID'. The description only says 'by ID', adding no 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 'Retrieve an invoice by ID from Lexware' clearly uses a verb (Retrieve) and a resource (invoice by ID). It distinguishes from siblings like lexware_create_invoice, lexware_download_invoice_file, etc., which have different actions.

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 description implies use when you need an invoice by ID, but does not mention when not to use or differentiate from other get methods (e.g., lexware_get_credit_note).

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.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering behavioral traits. The description only restates the basic action and adds no further behavioral context (e.g., error handling, permissions).

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 that immediately states the verb and resource. It is concise and front-loaded with essential information, 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?

Given the tool's simplicity (one parameter, robust annotations, no output schema), the brief description is mostly sufficient. However, it could briefly hint at the return value or typical response structure to enhance 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?

The input schema has 100% coverage with a description for the 'id' parameter ('Order confirmation UUID'). The tool description does not add any additional meaning or details 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' and the resource 'order confirmation by ID from Lexware', which precisely distinguishes it from sibling tools like lexware_create_order_confirmation and lexware_download_order_confirmation_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 (e.g., when to retrieve vs. download or pursue). There is no mention of prerequisites, context, 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_paymentsGet PaymentsA

Read-onlyIdempotent

Get payment details for a specific voucher.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Voucher 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 safety profile is clear. The description adds no additional behavioral context beyond what the name and schema imply. It doesn't disclose edge cases like missing voucher or return format, but given annotation coverage, it is minimally 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 a single sentence of 6 words, direct and front-loaded. No unnecessary information; every word is functional.

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 read tool with one parameter and annotations, the description is acceptably brief. However, it lacks explanation of what 'payment details' includes, which is not covered by the output schema (none), so some context is missing.

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 one parameter 'id' described as 'Voucher UUID'. The description adds no extra meaning beyond the schema, so it meets the baseline but does not enhance understanding.

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 and resource: 'Get payment details for a specific voucher.' It distinguishes from sibling tools like lexware_get_voucher (which retrieves voucher data) and lexware_list_payment_conditions (which lists payment terms), 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 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 when to use lexware_get_voucher for general voucher info or lexware_list_payments (if it existed). No prerequisites or exclusions are mentioned.

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

lexware_get_profileGet ProfileA

Read-onlyIdempotent

Get the organization profile information.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/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. The description adds no new behavioral context beyond naming the resource, which is already evident from the title.

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 with no redundant words. It is appropriately 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 simple get operation with no parameters and annotations covering safety, the description adequately states what the tool retrieves. It could be slightly more explicit about the nature of 'profile information', but it is sufficient.

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 are defined, so the description does not need to add parameter semantics. According to the rubric, 0 parameters warrants a baseline of 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 verb 'Get' and the specific resource 'organization profile information', which distinguishes it from sibling tools that operate on different entities like articles, contacts, or vouchers.

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 versus alternatives. The name and description imply it is for fetching organization-level profile, but exclusions or context are not provided.

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

lexware_get_quotationGet QuotationB

Read-onlyIdempotent

Retrieve a quotation by ID from Lexware.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Quotation UUID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already convey readOnlyHint, idempotentHint, and destructiveHint. The description adds no extra behavioral context (e.g., response format, error handling). It 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, no fluff. Efficiently communicates the core purpose.

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 strong annotations. Description could clarify the returned object, but overall, for a get-by-ID operation, it is reasonably 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 has 100% description coverage for the id parameter, so the description's mention of 'by ID' adds no new meaning. 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 (retrieve) and resource (quotation by ID). It is specific, but among siblings like lexware_get_invoice, the description does not differentiate beyond the resource name.

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 similar get tools (e.g., get_invoice, get_credit_note). No mention of prerequisites or alternatives.

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

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, covering the safety profile. The description adds minimal extra beyond 'retrieve', which aligns with annotations. No mention of response format, but annotations compensate.

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 word earns its place, conveying the action, resource, and scope efficiently.

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 with one parameter and comprehensive annotations, the description is complete. It clearly communicates the core operation. No output schema exists, but the agent can infer the return value. No missing context for correct usage.

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 'id' parameter is well-described as 'Recurring template UUID' with format and pattern). The tool description does not add any additional parameter insights 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.

Purpose5/5

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

The description 'Retrieve a recurring invoice template by ID from Lexware' uses a specific verb ('retrieve') and resource ('recurring invoice template'), and clearly distinguishes from sibling tools like `lexware_list_recurring_templates` (list) and `lexware_deeplink_recurring_template` (deeplink).

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: use this tool when you have the UUID to fetch a specific template. It does not explicitly state when not to use it or mention alternatives, but the context from sibling names provides clarity. Lacks explicit exclusion guidance.

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 ArticlesA

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

A3.5/5.0

Behavior3/5

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive, covering safety traits. The description adds no behavioral context beyond that (e.g., no mention of rate limits, data freshness, or what 'all articles' entails). It is adequate but does not enhance transparency.

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 and key capability (pagination) with no extraneous words. It is appropriately front-loaded and easy 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?

The description omits mention of filter parameters (gtin, type, articleNumber) which are available and crucial for targeted queries. Saying 'List all articles' could mislead agents into thinking no filtering is possible. Given the presence of annotations and rich schema, the description does not sufficiently complete the context of the tool's capabilities.

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?

All 5 parameters have schema descriptions covering 100% of their meaning. The description adds no extra semantic value beyond stating 'optional pagination.' The baseline score is 3, and no further information is provided.

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 ('List all articles') and includes the optional pagination feature, which distinguishes it from sibling tools like lexware_get_article that retrieve a single article. The verb-resource combination is specific and 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?

No guidance is given on when to use this tool versus alternatives (e.g., lexware_get_article for a single article, or tools for other resources). There are no explicit when-to-use or when-not-to-use instructions, which could lead to incorrect selection by an agent.

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.6/5.0

Behavior3/5

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

Annotations already declare read-only, idempotent, non-destructive. Description adds minimal behavioral context (pagination/filters) but lacks details like result set order or size limits. Not contradictory.

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 effectively communicates purpose and features. No wasted words; front-loaded with key actions.

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?

Despite 7 parameters and no output schema, description omits response structure (e.g., paginated list metadata). Incomplete for a list operation with rich filtering.

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 100% of parameters with descriptions. Tool description only summarizes 'optional pagination and filters', adding no meaning beyond 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?

Description clearly states verb 'List' and resource 'contacts', with added features 'optional pagination and filters'. Distinguishes from sibling tools like lexware_get_contact for single contacts.

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 vs alternatives (e.g., lexware_get_contact for single contact). Usage is implied by name and context, but not stated.

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.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the output includes tax classifications, providing useful behavioral context. 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 concise sentence that immediately conveys the purpose. 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?

Adequately describes the tool's output (list of countries with tax classifications) given no output schema. For a simple listing, this is sufficiently 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, so schema coverage is 100%. The description adds no param info (unnecessary) and 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?

Clearly states the action ('List') and the resource ('all available countries') along with what is included ('tax classifications'). Distinguishes from sibling tools which operate on different entities like articles, contacts, 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?

The description implies when to use: when country data with tax classifications is needed. No explicit alternatives or exclusions are needed given the specificity. 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_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

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds no behavioral details such as pagination, limits, or response format, which would be valuable 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, succinct sentence that immediately conveys the tool's function without unnecessary 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?

The tool is simple with no parameters, but the description could be improved by specifying the output structure (e.g., 'Returns a list of subscription objects with id, event type, and target URL'). Given no output schema, more detail would help.

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 input schema has no parameters, matching the description. Schema description coverage is 100% (vacuously), so no additional parameter info is needed.

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 all webhook event subscriptions in Lexware, which distinguishes it from related tools like get, create, and delete event subscriptions.

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 versus siblings like get_event_subscription, but the purpose is clear and the lack of parameters makes usage straightforward.

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.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, establishing safety and idempotency. The description 'List all available payment conditions' adds no behavioral specifics beyond annotations, such as rate limits or auth needs.

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 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?

Given no parameters, partial output schema, and annotations providing safety context, the description is nearly complete. However, it does not describe the return format or typical fields of payment conditions, leaving some 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?

No parameters exist; schema coverage is 100% (vacuous). Description adds nothing about parameters, but baseline for 0 params 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 uses a specific verb 'List' and resource 'payment conditions', clearly distinguishing it from sibling tools like lexware_list_posting_categories or lexware_list_vouchers. It states exactly what the tool does.

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., when payment conditions are needed vs other list tools). Lacks context or exclusions.

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.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, etc. The description adds minor context ('all available', 'for bookkeeping') without contradicting annotations. It provides limited additional behavioral details 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 sentence that conveys the tool's purpose without any extraneous information. 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?

Given no parameters, no output schema, and strong annotations, the description is fully complete. It explains what the tool does and its scope ('all available posting categories for bookkeeping'). No additional context required.

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% trivially. Per guidelines, 0 parameters yields a baseline of 4. The description adds no parameter documentation since none are needed.

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 ('List') and identifies the resource ('posting categories') clearly. It uniquely distinguishes from sibling tools as no other tool lists posting categories.

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 provide usage guidance or alternatives, but the simple nature of the tool (listing all categories, no parameters) makes its use self-evident. Lacks explicit when-to-use or when-not-to-use context.

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.5/5.0

Behavior2/5

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

The description merely restates the title and adds no behavioral context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint). It does not mention return format, pagination, or any 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.

Conciseness5/5

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

A single, clear sentence with no redundant information. Perfectly concise and appropriately front-loaded.

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 read-only tool with solid annotations, the description is adequate but lacks detail on what a 'print layout template' is and how the results can be used. It does not reference the output schema (missing) or explain any limitations.

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% and description needs no parameter details. The baseline of 4 applies, and the description adds no param semantics, 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 available print layout templates' uses a specific verb ('List') and resource ('print layout templates'), clearly distinguishing it from sibling tools focused on articles, contacts, vouchers, etc.

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 other list tools, nor any prerequisites or context for when print layout templates are relevant.

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.3/5.0

Behavior3/5

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds no further disclosure beyond the tool's existence.

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 redundancy. It is appropriately 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?

With no output schema, the description lacks details on return structure. However, given simple parameters and annotations, it is minimally adequate.

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 page and size parameters. 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.

Purpose4/5

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

The description clearly states the tool lists recurring invoice templates, but it does not differentiate from sibling tools like lexware_get_recurring_template.

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 when to list vs get a specific template.

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

Behavior3/5

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

Annotations already indicate destructiveHint=true. The description adds context about the endpoint and the effect of finalize (immediately paid-off, reducing invoice open amount). However, it does not broadly disclose the destructive nature (e.g., that it reduces the preceding invoice's open amount) beyond the parameter description. The main description could be more explicit about the mutation's impact.

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 concise sentences that front-load the purpose and key behavioral detail. It maps directly to the endpoint and explains the critical finalize parameter without extraneous information. Every sentence serves a clear purpose.

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 has 3 parameters with full schema descriptions, and the description covers the core functionality. It lacks explicit mention of return values or error conditions, but given the presence of sibling tools and clear purpose, it is sufficiently complete. The finalize parameter description in schema includes reduction of invoice open amount, which is useful context.

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 the baseline is 3. The description adds extra meaning by mapping parameters to the endpoint URL and explaining the finalize parameter's effect. It also references the body shape as similar to lexware_create_credit_note, which aids understanding for users familiar with that tool.

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 'Create' and the resource 'credit note', with the specific context 'as a follow-up to a preceding invoice'. This distinguishes it from sibling tools like lexware_create_credit_note (which presumably creates a standalone credit note) and lexware_pursue_invoice (which would pursue an invoice instead).

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 this tool (to create a credit note following an invoice) and explains the finalize parameter behavior. It does not explicitly mention alternatives or when not to use it, but the condition 'preceding invoice' is clear. The sibling tools are listed but not referenced, so the guideline is good but not explicit about exclusions.

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

A3.9/5.0

Behavior3/5

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

Annotations already indicate it is a write operation (readOnlyHint=false), non-destructive, and non-idempotent. The description adds that it creates a delivery note and gives the HTTP method/endpoint, but does not disclose behavioral traits like required permissions or effects of invalid preceding voucher. With annotations present, the bar is lower, but no extra value beyond what is obvious is provided.

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 primary purpose, and includes the endpoint mapping. Every sentence is relevant and there is 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?

Given the tool complexity (simple but with a nested body parameter), the description references API docs for full schema, which helps. However, it lacks information about return values (no output schema), prerequisites (e.g., voucher existence), or error conditions. The sibling set is large, and more differentiation would be beneficial. Overall 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?

Schema coverage is 100% with both parameters documented. The description adds the endpoint mapping but no additional semantic detail beyond the schema. The body parameter's note 'Same shape as lexware_create_delivery_note' is helpful but vague; it does not fully compensate since coverage is already high, 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 states the specific verb 'Create' and resource 'delivery note as a follow-up to a preceding quotation or order confirmation', clearly distinguishing it from sibling tools like lexware_create_delivery_note and other pursue tools.

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 (as a follow-up to a quotation or order confirmation) and implies not to use it for standalone delivery notes. However, it does not explicitly name the alternative lexware_create_delivery_note, though it is present in the sibling list. The endpoint mapping provides additional context.

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

A3.9/5.0

Behavior4/5

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

Beyond annotations, the description states that dunnings are created in draft mode and need not be finalized. This adds behavioral context not covered by the readOnlyHint or destructiveHint 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 efficiently convey endpoint, purpose, and draft mode behavior. No superfluous information.

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 covers creation and draft mode but omits what the response contains (e.g., dunning ID), which is relevant given no output schema. Adequate but not fully 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 descriptions already present. The description adds brief mention of key fields in the body but does not significantly enhance understanding 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?

Clearly states the tool creates a dunning as a follow-up to a preceding invoice, referencing the specific endpoint. This distinguishes it from other voucher-related tools in the sibling list (e.g., create_invoice, 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 Guidelines3/5

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

The description mentions using it as a follow-up to an invoice but lacks explicit guidance on when not to use it or alternatives among the many sibling tools. The context is clear but not exhaustive.

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.5/5.0

Behavior4/5

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

Behavior is well-described: it creates an invoice and can optionally finalize it. The annotations (readOnlyHint false, destructiveHint false) align. The description adds detail about the finalize parameter and endpoint mapping. However, the openWorldHint is true but not explained, so minor gap.

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 concise sentences plus endpoint detail. No unnecessary words; each sentence adds value. Front-loaded with purpose and 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?

Given no output schema, the description omits return value details. However, parameters are fully covered, behavior is clear, and the endpoint mapping provides a hint. Could briefly mention what is returned, but still sufficient for an agent to use 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?

Every parameter is described in the schema and the description adds extra meaning: endpoint mapping, explanation of finalize, and reference to lexware_create_invoice for the body structure. This goes 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 tool creates a new invoice as a follow-up to preceding sales vouchers (quotation, order confirmation, or delivery note). It distinguishes from creating an invoice from scratch (lexware_create_invoice) by specifying the preceding voucher context.

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 this tool (after a preceding voucher) and implies alternative (lexware_create_invoice) for invoices without a preceding voucher. It does not explicitly state when not to use it, but the 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_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/5.0

Behavior3/5

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

Annotations already indicate it's a write operation (readOnlyHint false) and non-destructive. The description adds the endpoint mapping and states 'create,' which is consistent. It does not add further behavioral details like idempotency or error modes, 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?

Two sentences with no wasted words. The first sentence defines purpose and prerequisite, the second gives the API mapping. 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 two-parameter create tool with openWorldHint and no output schema, the description is largely complete. It explains the purpose, prerequisite, and endpoint. It could mention that the operation is not idempotent, but overall it provides enough context for correct usage.

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?

Both parameters have descriptions in the schema (100% coverage), so baseline is 3. The body description references another tool for shape, which adds some value, but does not provide the full schema. This is sufficient given the open world hint.

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 order confirmation as a follow-up to a preceding quotation, with a specific verb and resource. It distinguishes from sibling pursue tools (e.g., pursue_invoice) by mentioning the quotation prerequisite and the endpoint.

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 (after a quotation) and provides the endpoint. It could explicitly mention not to use when no preceding quotation exists or contrast with lexware_create_order_confirmation, but the context is clear enough for an agent.

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

A4.2/5.0

Behavior4/5

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

Description adds behavioral context about optimistic locking ('must include the version field'), which is beyond annotations. Annotations already indicate idempotent hint and non-destructive, so bar is lowered; description enriches understanding.

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: first states purpose, second adds critical requirement. No wasted words; front-loaded with key 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 2-parameter tool with annotations and no output schema, the description provides essential behavioral context (optimistic locking). It does not explain the full return or error handling, but that is acceptable.

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 descriptions for both parameters. The description adds value by emphasizing the version field requirement for optimistic locking, which is not fully captured in the schema propertyNames or 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?

Clearly states 'Update an existing article' with specific verb and resource, and is distinct from sibling tools like create, delete, and get.

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?

Implies usage for updating articles but provides no explicit guidance on when to use vs alternatives (e.g., when to use update vs create). No exclusions or when-not-to-use indicated.

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.4/5.0

Behavior4/5

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

Discloses optimistic locking via version field, which is beyond annotations. No contradictions; adds meaningful behavioral context despite annotations already present.

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 waste. The first sentence states purpose, the second adds the critical requirement. Ideal length.

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 simplicity, annotations, and schema coverage, the description is largely sufficient. Lacks details on constraints or typical usage flow, but within acceptable bounds.

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 descriptions. The description adds emphasis on the version field requirement, providing extra clarity 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 'Update an existing contact', specifying the verb and resource. It distinguishes from sibling tools like create or get 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 context is clear for updating a contact, but no explicit when-not or alternative guidance is provided. The requirement for the version field implies needing to fetch first.

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

A4.2/5.0

Behavior4/5

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

Annotations already indicate non-read-only and idempotent behavior. The description adds transparency about the version field requirement for concurrency control. No contradictions 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 extremely concise at two sentences and 14 words, with no superfluous information. The action and key requirement are front-loaded.

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?

Despite having annotations and schema coverage, the description lacks information about the return value (no output schema) and does not explain what the body should contain beyond the version field. The tool's response is not described, leaving the agent with incomplete context.

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 reinforces that the body must contain a version field, adding extra context beyond the schema's description of 'Voucher JSON with version field'. This clarifies the key parameter semantic.

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 'Update' and the resource 'existing bookkeeping voucher'. It distinguishes from sibling tools like 'lexware_create_voucher' by specifying 'existing', 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 explicitly mentions the requirement for a version field for optimistic locking, guiding the agent on how to use the tool correctly. However, it does not explicitly contrast with alternatives like 'lexware_create_voucher' or specify 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_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.5/5.0

Behavior5/5

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description goes beyond by detailing the public key retrieval and caching mechanism, the option to override with an environment variable for production, and the critical warning about not modifying the request body. These details add significant behavioral context.

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 exceptionally concise, consisting of two sentences that cover purpose, usage instructions, behavioral details, and production considerations without any redundant 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?

Given that the tool has no output schema and the input schema is fully covered, the description provides all necessary context: the verification algorithm, handling of the body, caching behavior, and production override. It is complete for an agent to understand and use 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?

The input schema already has 100% coverage with clear descriptions for both parameters (payload and signature). The description repeats the warning about not transforming the payload, which adds some emphasis but not new semantic information 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 tool's function: verifying a Lexware webhook signature using RSA-SHA512. It identifies the exact header and algorithm, and distinctively separates this security tool from the numerous CRUD sibling tools.

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 explicit instructions on how to use the tool: pass the exact raw body bytes, avoid JSON transformations. It also explains caching behavior and the override environment variable. However, it does not explicitly mention when not to use this tool or alternatives, though the uniqueness of the tool makes this less critical.

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.1/5.0

Scored 2026-09-09 18:45 across 66 tools

Disambiguation4/5

Most tools target a unique resource-action pair, and the repetitive structure (get/download/deeplink/pursue) is clear per document type. The main confusion risk is between list_vouchers and list_voucherlist, and between generic file upload/download and voucher/file-specific variants, though descriptions do clarify these.

Naming Consistency4/5

All tools follow a consistent lexware_verb_noun pattern with snake_case throughout. Minor deviations like list_voucherlist (noun already contains 'list') and get_payments (rather than list_payments) keep this from being a perfect 5.

Tool Count2/5

With 66 tools, the surface is very large and will likely overwhelm an agent choosing among options. The breadth reflects a full ERP domain, but it far exceeds the 3-15 well-scoped range and feels heavier than necessary.

Completeness4/5

The server covers core lifecycles well: articles and contacts have CRUD, sales documents have create/get/download/pursue/deeplink, and vouchers have create/get/update/upload/list. Minor gaps exist—such as no create operation for down payment invoices and no update/delete for most document types—but these may reflect API constraints rather than missing coverage.

Maintenance

ActivityMaintained

ResponsivenessSlow

Resources

Need Help?

Related Servers

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
2

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
28 npm
-
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 2 months 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 14 days ago (2026-09-12 19:59 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 2 months ago (2026-08-04 14:28 UTC)
28
9 npm
MIT