Skip to main content
Glama
joosthel

sevdesk-mcp

by joosthel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create a voucher

sevdesk_create_voucher

Creates a sevDesk voucher from supplier, date, tax rule, and line items, defaulting to draft status so you can review it before booking.

Instructions

Create a voucher via /Voucher/Factory/saveVoucher. Defaults to status 50 (Entwurf) so nothing is booked without you reviewing it in sevDesk. Check sevdesk_receipt_guidance for the account's allowed tax rules first — expense-side reverse charge is 12/13/14, not 5. WRITE operation. For anything this wrapper does not cover, use sevdesk_call with operationId 'voucherFactorySaveVoucher'. ⚠️ This tool can change data in sevDesk.

Input Schema

NameRequiredDescriptionDefault
extraNoAdditional top-level voucher fields merged into the payload verbatim.
dryRunNoShow the payload instead of sending it.
statusNo50 = Entwurf, 100 = offen, 1000 = bezahlt (default 50).
payDateNoPayment date, dd.mm.yyyy — only with status 1000.
fileNameNoFilename token returned by sevdesk_upload_voucher_file.
positionsYesLine items.
taxRuleIdYesVAT regulation id — every rule sevDesk accepts on a voucher, both sides. Required — never guessed. sevdesk_receipt_guidance lists the ones the booking account actually allows. Expense rules go with creditDebit C, revenue rules with D.
creditDebitNoC = credit, D = debit.
descriptionNoDocument/invoice number.
voucherDateYesVoucher date, dd.mm.yyyy.
supplierNameYesSupplier name as it should appear on the voucher.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.5.0
    • changedInput schema / properties / taxRuleId / description
      Previous value: -"VAT regulation id."New value: +"VAT regulation id — every rule sevDesk accepts on a voucher, both sides. Required — never guessed. sevdesk_receipt_guidance lists the ones the booking account actually allows. Expense rules go with creditDebit C, revenue rules with D."
    • changedInput schema / properties / taxRuleId / enum
      Previous value: -[
-  "1",
-  "2",
-  "3",
-  "4",
-  "5",
-  "11"
-]New value: +[
+  "1",
+  "2",
+  "3",
+  "4",
+  "5",
+  "8",
+  "9",
+  "10",
+  "11",
+  "12",
+  "13",
+  "14",
+  "16",
+  "17",
+  "22"
+]
    • changedInput schema / required
      Previous value: -[
-  "supplierName",
-  "voucherDate",
-  "positions"
-]New value: +[
+  "supplierName",
+  "voucherDate",
+  "taxRuleId",
+  "positions"
+]
  2. First observedv0.4.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds real context: the draft-by-default safety behavior, the warning that it changes data, and the domain pitfall that expense reverse charge is 12/13/14 rather than 5. It does not cover permission requirements, duplicate-voucher risk (despite a sevdesk_find_duplicates sibling), or what the call returns, so it stops short of a 5.

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

Conciseness4/5

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

Front-loaded with the core action and endpoint, then constraints, then escalation path — a sensible reading order with little waste. The closing '⚠️ This tool can change data in sevDesk' is partially redundant with the earlier 'WRITE operation' flag, a small duplication that keeps it from a 5.

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

Completeness4/5

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

For an 11-parameter tool with nested line items and no output schema, the description supplies the workflow prerequisite, the safety default, and the override path. The remaining gap is that it never says what a successful call returns (e.g. the new voucher id) or how a created draft should be verified or finalized afterward.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by adding meaning the schema does not: taxRuleId must never be guessed and must come from receipt_guidance, and expense rules pair with creditDebit C while revenue rules pair with D. The status default rationale is also explained rather than merely restated.

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

Purpose5/5

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

States a specific verb and resource plus the exact endpoint ('Create a voucher via /Voucher/Factory/saveVoucher'), which separates it cleanly from sevdesk_create_invoice and the list/get voucher siblings. It also bounds its own scope by naming the fallback path (sevdesk_call) for anything the wrapper doesn't cover.

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?

Explicitly tells the agent to check sevdesk_receipt_guidance first, explains the default status 50 exists so nothing is booked without review, and names the alternative (sevdesk_call with operationId 'voucherFactorySaveVoucher') for uncovered cases. When-to-use, prerequisite ordering, and escape hatch are all present.

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

Deploy Server

Other Tools