Skip to main content
Glama
Sign In
Storno CLI

Storno CLI

Official
by stornoro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

declarations_create

Create a tax declaration for a company and period; auto-populate VAT, payroll, SAF-T, and form-based types from invoices or JSON input for validation and filing.

Instructions

Create a new tax declaration. VAT and payroll types (d394, d300, d390, d100, d112) are auto-populated from the company's invoices for the period; so are 'd301' (decont special de TVA for companies not registered for VAT: purchases from abroad with self-assessed VAT, monthly) and 'd398' (OSS / regimul UE: sales to consumers in other member states — invoices typed special-regime art. 314-315, plus untyped invoices that charge VAT to a non-VAT-registered EU buyer; amounts in EUR at the quarter-end ECB rate; quarterly, any month of the quarter) and 'd406' (SAF-T: the whole audit file — header, accounts, customers / suppliers, tax codes, the ledger derived from the documents and the source documents — for the company's VAT period, periodType monthly or quarterly). Form-based types are filled from plain JSON: 'd212' (Declarația unică, rent income; month 12) and 'c168' (rental contract registration/amendment/termination; month 12) take data.input in the shape of declaration_form_spec, and c168 needs data.attachments [{name, contentBase64}] (the scanned contract / termination document) for the PDF. Then declarations_validate → declarations_file_via_agent.

Input Schema

NameRequiredDescriptionDefault
dataNoFor d212 / c168: { input: <form input>, attachments?: [{name, contentBase64}] }. Responses return attachments as {name, size, mime, stored} without the content; sending that shape back keeps the stored files
typeYesDeclaration type
yearYesDeclaration year (e.g. 2026)
monthYesDeclaration month (1–12)
dosarIdNoAttach the new declaration to this dosar
companyIdNoCompany UUID (overrides STORNO_COMPANY_ID env var)
periodTypeNoPeriod type (default: "monthly")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.48
    • changedInput schema / properties / data / description
      Previous value: -"For d212 / c168: { input: <form input>, attachments?: [{name, contentBase64}] }"New value: +"For d212 / c168: { input: <form input>, attachments?: [{name, contentBase64}] }. Responses return attachments as {name, size, mime, stored} without the content; sending that shape back keeps the stored files"
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "d394",
-  "d300",
-  "d390",
-  "d100",
-  "d112",
-  "d212",
-  "c168"
-]New value: +[
+  "d394",
+  "d300",
+  "d390",
+  "d301",
+  "d398",
+  "d406",
+  "d100",
+  "d112",
+  "d212",
+  "c168"
+]
  2. Changed3 schema fields changedv1.0.37
    • addedInput schema / properties / data
      Added value: +{
+  "additionalProperties": {},
+  "description": "For d212 / c168: { input: <form input>, attachments?: [{name, contentBase64}] }",
+  "type": "object"
+}
    • addedInput schema / properties / dosarId
      Added value: +{
+  "description": "Attach the new declaration to this dosar",
+  "format": "uuid",
+  "type": "string"
+}
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "d394",
-  "d300",
-  "d390",
-  "d100",
-  "d112"
-]New value: +[
+  "d394",
+  "d300",
+  "d390",
+  "d100",
+  "d112",
+  "d212",
+  "c168"
+]
  3. First observedv1.0.17

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare this is a non-idempotent, non-destructive write, so the safety profile is covered. The description adds real behavioral context beyond that: declarations are auto-derived from the company's invoices, d398 converts amounts at the quarter-end ECB rate, d406 assembles the full SAF-T audit file, and c168 requires scanned attachments for the PDF. It does not say whether the created declaration is a draft or what happens on duplicate creation (relevant 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.

Conciseness3/5

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

The purpose is front-loaded, but the remainder is one enormous semicolon-chained sentence with deeply nested parentheses, which is hard to scan and makes per-type facts difficult to locate. Every clause carries information, so the problem is structure rather than padding.

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 7-parameter, nested-object, mutation tool with no output schema, the description covers per-type sourcing behavior, the `data` shape for form types, and the downstream workflow. It omits what the call returns (an ID? a draft object?) and any duplicate/error behavior, which matters for a non-idempotent create.

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

Parameters5/5

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

The schema's `type` enum carries only "Declaration type," and the description supplies the missing semantics for every value: which are auto-populated from invoices, which are form-based and need `data.input`, and which need `data.attachments`. It also adds period constraints the schema lacks (d212/c168 use month 12, d398 is quarterly but accepts any month of the quarter, d406 uses `periodType` monthly or quarterly).

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?

States a specific verb and resource ("Create a new tax declaration") and immediately scopes it by enumerating every supported declaration type. An agent can distinguish this creator tool from declarations_prepare, declarations_build, or dosare_d212_create by the type list alone.

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?

Ends with an explicit workflow handoff: "Then declarations_validate → declarations_file_via_agent," which tells the agent what to do after creation. It also splits types into auto-populated vs. form-based, implicitly telling the agent which path to take. It never explicitly excludes the overlapping siblings (dosare_d212_create, dosare_c168_create, declaration_build), so the when-not is missing.

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