Skip to main content
Glama
Sign In
Storno CLI

Storno CLI

Official
by stornoro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

invoices_create

Creates a new draft invoice from line items and client details, keeping it editable until issued; use the issue tool to finalize and generate XML/PDF.

Instructions

Create a new draft invoice. Requires at least one line item and either a clientId or receiverName/receiverCif. The invoice starts in "draft" status and can be edited until issued. Use invoices_issue to finalize and generate XML/PDF.

Input Schema

NameRequiredDescriptionDefault
linesYesInvoice line items (at least one required)
notesNoPublic notes visible to the client
collectNoRecord an immediate payment. Pass true for full payment with defaults, or an object with value/type/issueDate/documentNumber/mentions for details.
dueDateNoPayment due date in ISO 8601 format (YYYY-MM-DD)
clientIdNoClient UUID (from clients_list). Either clientId or receiverName should be provided.
currencyNoISO 4217 currency code (default: RON)
issuerIdNoIssuer ID number
languageNoDocument language for PDF generation (default: ro)
mentionsNoAdditional legal mentions on the invoice
seriesIdNoInvoice series UUID (from document_series_list). Uses default if not provided.
companyIdNoCompany UUID override (uses active company if not set)
issueDateYesInvoice issue date in ISO 8601 format (YYYY-MM-DD)
deputyAutoNoDeputy vehicle registration number
deputyNameNoDeputy/representative name
issuerNameNoName of person issuing the invoice
salesAgentNoSales agent name
orderNumberNoPurchase order number
plataOnlineNoEnable online payment via Stripe (default: from company settings)
platitorTvaNoWhether sender is VAT payer (default: false)
receiverCifNoReceiver tax ID / CIF (used together with receiverName when no client entity exists)
vatIncludedNoWhen used with autoApplyVatRules, sets whether unit prices include VAT on all lines. Ensures correct totals after VAT rules change rates.
documentTypeNoDocument type (default: invoice)
exchangeRateNoExchange rate relative to RON (default: 1.0)
internalNoteNoInternal note (not visible to the client)
paymentTermsNoPayment terms description (e.g., "Net 30")
receiverNameNoReceiver name (used when no client entity exists). Either clientId or receiverName should be provided.
taxPointDateNoTax point date if different from issue date (YYYY-MM-DD)
paymentMethodNoPayment method: bank_transfer (default), cash, card, cheque, other
tvaLaIncasareNoVAT on collection / TVA la încasare (default: false)
ublExtensionsNoUBL extension fields for advanced e-Factura compliance. These map directly to UBL XML elements not covered by the standard invoice fields.
buyerReferenceNoBuyer reference identifier (BT-10)
contractNumberNoContract reference number
idempotencyKeyNoIdempotency key to prevent duplicate creation
penaltyEnabledNoEnable late payment penalty (default: false)
invoiceTypeCodeNoTax regime / invoice type code. standard = default commercial invoice; reverse_charge = taxare inversa; the other values map to specific Romanian tax-code articles.
deliveryLocationNoDelivery address
parentDocumentIdNoParent document UUID (required for credit notes / refunds)
penaltyGraceDaysNoGrace period in days before penalty starts applying
projectReferenceNoProject reference number
taxPointDateCodeNoTax point date code
autoApplyVatRulesNoAuto-apply VAT rules (reverse charge for VIES-valid EU clients, OSS destination rate for non-VIES EU clients). Default: false.
showClientBalanceNoShow client balance on invoice (default: false)
deputyIdentityCardNoDeputy ID card number
businessProcessTypeNoBusiness process type (e.g., "urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1")
penaltyPercentPerDayNoDaily penalty percentage (e.g., 0.05 for 0.05% per day)
tenderOrLotReferenceNoTender or lot reference
despatchAdviceReferenceNoDespatch advice reference
buyerAccountingReferenceNoBuyer accounting reference
invoicedObjectIdentifierNoInvoiced object identifier
receivingAdviceReferenceNoReceiving advice reference

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.17

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is covered. The description adds real lifecycle context beyond that: the record starts in 'draft', remains editable until issued, and issuing/XML/PDF generation is a separate call. It does not mention the idempotencyKey parameter's role in preventing duplicate creation, which matters given idempotentHint=false.

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?

Four short sentences, front-loaded with the action and its prerequisites, then lifecycle, then the follow-up tool. Nothing is repeated from the schema and nothing is wasted.

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 50-parameter, deeply nested creation tool with no output schema, the description covers purpose, minimum viable input, state transitions and the next step in the workflow. It omits how defaults are resolved (currency RON, series, VAT rules, company settings) and what the create response returns, but the 100%-covered schema carries most of that weight.

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 would be 3, but the description adds a cross-field constraint the schema does not express (only 'lines' and 'issueDate' are in required; the clientId-or-receiverName/CIF choice is enforced only in prose). That is genuine value beyond the structured fields.

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?

Specific verb + resource + scope: 'Create a new draft invoice' immediately distinguishes it from invoices_issue, invoices_update and invoices_get. The draft-only nature is stated explicitly, so an agent knows exactly what artifact is produced.

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

Usage Guidelines4/5

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

Gives prerequisites ('at least one line item and either a clientId or receiverName/receiverCif') and routes finalization to invoices_issue. It does not disambiguate the equally named siblings proforma_invoices_create, recurring_invoices_create or delivery_notes_create, which an agent could plausibly confuse with this one.

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