Skip to main content
Glama
stornoro

Storno CLI

by stornoro

receipts_create

Create draft POS receipts with payment details, line items, and optional fiscal register info. Retry-safe via idempotency keys for queued offline sales.

Instructions

Create a new receipt (bon fiscal) in draft status. Receipts document point-of-sale transactions with payment method details and optional fiscal register information. Can later be issued and converted to invoices. A default receipt series is auto-assigned if neither seriesId nor documentSeriesId is provided.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linesYesArray of line items (minimum 1 required)
notesNoPublic notes on the receipt
clientIdNoUUID of the client (optional for receipts)
currencyYesCurrency code (e.g., RON, EUR, USD)
issuerIdNoUUID of the issuer user
mentionsNoAdditional mentions or instructions
seriesIdNoUUID of the receipt series (uses default series if not provided)
companyIdNoCompany UUID (overrides configured default)
issueDateYesDate of issue (YYYY-MM-DD)
issuerNameNoName of person issuing the receipt
salesAgentNoSales agent name
cardPaymentNoAmount paid by card (for mixed payments)
cashPaymentNoAmount paid in cash (for mixed payments)
customerCifNoCustomer tax ID / CIF (when no clientId is provided)
customerNameNoCustomer name (when no clientId is provided)
exchangeRateNoExchange rate to base currency (default: 1.0 for RON)
fiscalNumberNoFiscal receipt number assigned by the cash register
internalNoteNoInternal note (not visible to customer)
otherPaymentNoAmount paid by other method, e.g. meal ticket (for mixed payments)
paymentMethodNoPayment method used for the transaction
idempotencyKeyNoUnique key for retry-safe submissions. Repeat calls with the same key return the originally created receipt instead of creating a duplicate. Recommended for queued offline POS sales and ambiguous timeouts.
cashRegisterNameNoName or identifier of the cash register / fiscal printer
documentSeriesIdNoUUID of the document series to use (alternative to seriesId; uses default receipt series if neither is provided)
projectReferenceNoRelated project or order reference
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that receipts are created in draft status and can be converted to invoices, plus the default series auto-assignment behavior. But it doesn't mention validation rules, permissions required, or what happens on success/failure beyond the implicit creation semantics.

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?

Three concise sentences covering purpose, lifecycle, and series behavior. Efficient and front-loaded with the core purpose. No wasted words, but could be slightly more structured given the 24-parameter surface area.

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 create operation with 24 params and complete schema coverage, the description covers the essential purpose and lifecycle. It lacks guidance on relationship between payment fields (cashPayment/cardPayment/otherPayment vs paymentMethod), idempotency usage context, or edge cases like clientId vs customerName alternatives — though the schema descriptions partially cover these.

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

Parameters3/5

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

Schema coverage is 100%, so the schema fully documents all 24 parameters. The description adds context on seriesId vs documentSeriesId fallback behavior. It doesn't add meaning for paymentMethod, lines, or other parameters, but that's acceptable given complete 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?

Clear specific verb+resource: 'Create a new receipt (bon fiscal) in draft status.' Distinguishes from siblings by stating receipts document point-of-sale transactions, can be issued/converted to invoices, and noting default series auto-assignment. Well-defined scope that separates it from invoices_create and proforma_invoices_create.

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 draft-status creation and later issuance/conversion path, giving context on the receipt lifecycle. States the default series behavior when neither seriesId nor documentSeriesId is provided. However, it doesn't explicitly differentiate from receipts_issue/convert_to_invoice or mention when receipts_create vs invoices_create is appropriate.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stornoro/storno-cli'

If you have feedback or need assistance with the MCP directory API, please join our Discord server