Skip to main content
Glama
stornoro

Storno CLI

by stornoro

delivery_notes_create

Creates a draft delivery note documenting physical delivery of goods or services, with optional deputy and e-Transport details, for later conversion to invoices.

Instructions

Create a new delivery note in draft status. Delivery notes document physical delivery of goods or services and can later be converted to invoices. Include deputy information for proof of delivery. A default delivery_note 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 about the delivery
dueDateYesDue date for invoicing (YYYY-MM-DD)
clientIdYesUUID of the client
currencyYesCurrency code (e.g., RON, EUR, USD)
issuerIdNoUUID of the issuer user
mentionsNoAdditional mentions or instructions
seriesIdNoUUID of the delivery note series (uses default series if not provided)
companyIdNoCompany UUID (overrides configured default)
issueDateYesDate of issue (YYYY-MM-DD)
deputyAutoNoVehicle registration number used for delivery
deputyNameNoName of person who received the delivery
issuerNameNoName of person issuing the delivery note
salesAgentNoSales agent name
exchangeRateNoExchange rate to base currency (default: 1.0 for RON)
internalNoteNoInternal note (not visible to client)
deliveryLocationNoFull address where goods were delivered
documentSeriesIdNoUUID of the document series to use (alternative to seriesId; uses default delivery_note series if neither is provided)
projectReferenceNoRelated project or order reference
deputyIdentityCardNoID card number of the deputy
etransportTrailer1NoFirst trailer registration number
etransportTrailer2NoSecond trailer registration number
etransportEndCountyNoEnd county code (1-52). Required for e-Transport (BR-211)
etransportEndNumberNoEnd street number
etransportEndStreetNoEnd street name (2-100 chars)
etransportEndLocalityNoEnd locality name (2-100 chars)
etransportStartCountyNoStart county code (1-52 per ANAF nomenclature, e.g., 4=Bacau, 40=Bucuresti). Required for e-Transport (BR-210)
etransportStartNumberNoStart street number
etransportStartStreetNoStart street name (2-100 chars per BR-215)
etransportEndOtherInfoNoEnd additional address info
etransportPostIncidentNoPost-incident declaration (after the transport was completed)
etransportEndPostalCodeNoEnd postal code
etransportOperationTypeNoOperation type code: 10 (intra-community acquisition), 12 (intra-community delivery), 20 (transaction in national territory between two different entities with goods moving domestically), 30 (domestic transport document TTN), 40 (import), 50 (export), 60 (goods not released for circulation)
etransportStartLocalityNoStart locality name (2-100 chars per BR-214)
etransportTransportDateNoTransport start date (YYYY-MM-DD)
etransportVehicleNumberNoVehicle registration number (e.g., "BC01ABC"). Schematron BR-031: 3-20 uppercase alphanumeric chars
etransportStartOtherInfoNoStart additional address info
etransportStartPostalCodeNoStart postal code
etransportTransporterCodeNoTransporter CUI/CIF (numeric only, e.g., "31385365"). Must match ANAF format per BR-002
etransportTransporterNameNoTransporter legal name (e.g., "UNIVERSAL EQUIPMENT PROJECTS SRL")
etransportTransporterCountryNoTransporter country code (ISO 3166-1 alpha-2, e.g., "RO"). For TTN (opType 30) must be "RO" per BR-005
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 draft status creation and series auto-assignment behavior, which is useful. However, it does not disclose side effects (e.g., whether creating consumes a series number, validation constraints beyond schema, or permissions required). The draft-status disclosure and e-Transport field context are helpful but not comprehensive for a 41-parameter 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.

Conciseness4/5

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

The description is three sentences with the key purpose front-loaded in the first sentence. It includes relevant lifecycle context and series behavior. It is appropriately sized for a complex tool without being verbose, though it could condense slightly.

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 very complex 41-parameter tool with no output schema and no annotations, the description provides a reasonable overview but doesn't explain return values, validation outcomes, or e-Transport submission implications. Given the complexity (e-Transport BR code constraints referenced in schema), the description could benefit from noting that many e-Transport fields are conditional on opType, though the schema descriptions already capture this.

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 all 41 parameter descriptions exist in the schema. The tool description adds minimal parameter-level value beyond the schema, though it highlights deputy information for proof of delivery and the series defaulting logic. Given full schema coverage, baseline 3 is appropriate—the schema does the heavy lifting and the description adds a couple of contextual notes.

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 starts with a clear, specific verb+resource statement: 'Create a new delivery note in draft status.' It further explains it documents physical delivery and can be converted to invoices, distinguishing it from the sibling delivery_notes_update and related tools. The purpose is 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 clearly states the tool creates draft delivery notes and mentions the deputy information requirement for proof of delivery. It doesn't explicitly name alternatives, but the convert/issue/update siblings imply lifecycle usage. The series auto-assignment behavior ('default series if neither provided') provides helpful context for when not to specify series params.

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