Skip to main content
Glama
Sign In
Storno CLI

Storno CLI

Official
by stornoro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

recurring_invoices_update

Idempotent

Update an existing recurring invoice template by UUID, including schedule, line items, client, or billing details; provide at least one field, and line updates replace all existing lines.

Instructions

Update an existing recurring invoice template. All fields are optional but at least one must be provided. When updating lines, the entire lines array replaces existing lines.

Input Schema

NameRequiredDescriptionDefault
uuidYesUUID of the recurring invoice template to update
linesNoArray of line items (replaces all existing lines)
notesNoNotes printed on every generated document; same placeholders as recurring_invoices_create ([[luna]], [[an]], [[curs]], [[suma:EXPR]], [[sold]], [[sold_anterior]], [[rata]])
balanceNoRunning balance in RON (null removes it); see recurring_invoices_create
clientIdNoUUID of the client
currencyNoISO 4217 currency code
seriesIdNoUUID of the document series
stopDateNoISO 8601 date to stop generation (null to remove)
companyIdNoCompany UUID (overrides configured default)
frequencyNoHow often to generate invoices
referenceNoHuman-readable reference
balanceStepNoExpression deducted from balance per issuance, e.g. "1900*curs"; null removes it
dueDateDaysNoDays after issue date for due date
dueDateTypeNoHow due date is calculated. days = N days after issue. fixed_day = fixed day of month.
documentTypeNoDocument type to generate
frequencyDayNoDay of month for generation (1-31)
paymentTermsNoPayment terms text
autoEmailTimeNoTime to send email (HH:mm)
frequencyMonthNoMonth for yearly generation (1-12)
penaltyEnabledNoEnable late payment penalties
dueDateFixedDayNoFixed day of month for due date (1-31)
invoiceTypeCodeNoTax regime / invoice type code
autoEmailEnabledNoAuto-send email on invoice generation
nextIssuanceDateNoISO 8601 date for next invoice generation (YYYY-MM-DD)
penaltyGraceDaysNoGrace period in days before penalties apply
autoEmailDayOffsetNoDays offset for email sending
penaltyPercentPerDayNoDaily penalty percentage

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.0.51
    • addedInput schema / properties / balance
      Added value: +{
+  "anyOf": [
+    {
+      "type": [
+        "number",
+        "string"
+      ]
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Running balance in RON (null removes it); see recurring_invoices_create"
+}
    • addedInput schema / properties / balanceStep
      Added value: +{
+  "description": "Expression deducted from balance per issuance, e.g. \"1900*curs\"; null removes it",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedInput schema / properties / lines / items / properties / priceExpression
      Added value: +{
+  "description": "With priceRule=expression: the unit price in the document currency computed at issuance, e.g. \"2000*curs - rata\" (2,000 EUR at the BNR rate minus what this issuance deducts from the running balance). Names: curs, curs_EUR…, rata, sold, sold_anterior, luna_nr, an. Negative results become 0.",
+  "type": "string"
+}
    • changedInput schema / properties / lines / items / properties / priceRule / description
      Previous value: -"Pricing rule. fixed: unitPrice as-is. updated_product: refresh from linked product on each issuance. bnr_rate: convert from referenceCurrency at BNR rate. bnr_rate_markup: same as bnr_rate plus markupPercent."New value: +"Pricing rule. fixed: unitPrice as-is. updated_product: refresh from linked product on each issuance. bnr_rate: convert from referenceCurrency at BNR rate. bnr_rate_markup: same as bnr_rate plus markupPercent. expression: unitPrice computed at issuance from priceExpression (document currency), e.g. \"2000*curs - rata\"."
    • changedInput schema / properties / lines / items / properties / priceRule / enum
      Previous value: -[
-  "fixed",
-  "updated_product",
-  "bnr_rate",
-  "bnr_rate_markup"
-]New value: +[
+  "fixed",
+  "updated_product",
+  "bnr_rate",
+  "bnr_rate_markup",
+  "expression"
+]
    • changedInput schema / properties / notes / description
      Previous value: -"Internal notes"New value: +"Notes printed on every generated document; same placeholders as recurring_invoices_create ([[luna]], [[an]], [[curs]], [[suma:EXPR]], [[sold]], [[sold_anterior]], [[rata]])"
  2. First observedv1.0.17

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds the non-obvious destructive-ish detail that the 'lines' array fully replaces existing lines, which is exactly the kind of behavior an agent must know before calling. It stops short of mentioning side effects on already-scheduled issuances (e.g., changing nextIssuanceDate).

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?

Three short sentences, front-loaded with purpose, then the invocation constraint, then the one surprising behavior. Every sentence carries distinct information and nothing is repeated.

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 27-parameter update tool, the description plus the fully documented schema and annotations give enough to call it correctly. The only soft spot is the phrase 'all fields are optional' while the schema requires uuid, which could momentarily confuse an agent about whether the template identifier is optional.

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% and every one of the 27 parameters, including complex ones like priceRule expressions and balance expressions, is documented in the schema. The description adds nothing parameter-specific beyond 'lines replaces existing lines', which the schema also states, so the baseline 3 applies.

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 ('Update an existing recurring invoice template'), so the agent knows exactly what entity is being mutated. It does not name or distinguish itself from nearby siblings such as recurring_invoices_create or recurring_invoices_toggle, leaving that inference to the agent.

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

Usage Guidelines3/5

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

Provides constraints that shape invocation ('all fields optional but at least one must be provided'), which is genuinely useful usage guidance. However, it never says when to prefer this over recurring_invoices_create, recurring_invoices_toggle, or issue_now, so alternative selection remains implicit.

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