Skip to main content
Glama
lazyants

lexware-mcp-server

by lazyants
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Quotation

lexware_create_quotation

Create a new Lexware quotation, either finalized immediately or as a draft. Includes Lexware text formatting for descriptions and remarks.

Instructions

Create a new quotation in Lexware; finalize=true finalizes at creation, false or omitted creates a draft. In introduction, lineItems[].description, and remark, use only Lexware formatting: bold, italic, and dash-prefixed list items separated by newlines.

Input Schema

NameRequiredDescriptionDefault
bodyYesQuotation JSON body with voucherDate, expirationDate, address (contactId or manual fields), lineItems (name, quantity, unitPrice), totalPrice, and taxConditions. In introduction, lineItems[].description, and remark, use only Lexware formatting: **bold**, __italic__, and dash-prefixed list items separated by newlines.
finalizeNoWhen true, finalize the quotation at creation via ?finalize=true. When false or omitted, create as draft.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv5.3.0
    • changedInput schema / properties / body / description
      Previous value: -"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."New value: +"Quotation JSON body with voucherDate, expirationDate, address (contactId or manual fields), lineItems (name, quantity, unitPrice), totalPrice, and taxConditions. In introduction, lineItems[].description, and remark, use only Lexware formatting: **bold**, __italic__, and dash-prefixed list items separated by newlines."
    • addedInput schema / properties / finalize
      Added value: +{
+  "description": "When true, finalize the quotation at creation via ?finalize=true. When false or omitted, create as draft.",
+  "type": "boolean"
+}
  2. First observedv3.0.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare the operation is not read-only, not destructive, not idempotent, and open-world. The description adds useful behavioral detail beyond that: finalize=true finalizes at creation, false or omitted creates a draft, plus formatting constraints for introduction, lineItems[].description, and remark. It does not cover error handling or authentication, but with annotations covering the safety profile this is a solid contribution.

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 compact sentences with zero waste. The core action and the finalize distinction are front-loaded, followed by the formatting constraint. Every phrase 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?

For a creation tool with a nested body object, 100% schema coverage, and no output schema, the description is nearly complete. It covers the key creation modes and formatting rules, though it could mention what is returned (e.g., a new quotation ID) or that the body must include required voucher fields.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description's statements about finalize behavior and Lexware formatting duplicate the schema's own parameter descriptions rather than adding new meaning, so it neither helps nor hurts.

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?

States a specific verb and resource ('Create a new quotation in Lexware'), which is clear and unambiguous. However, it does not differentiate this tool from its many create-siblings (e.g., lexware_create_invoice, lexware_create_credit_note), so an agent must infer the distinction from the tool name alone.

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?

Provides no guidance on when to use this tool versus alternatives such as lexware_create_invoice or when to retrieve an existing quotation via lexware_get_quotation. The only conditional information pertains to the finalize parameter, not to tool selection.

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