Skip to main content
Glama
nubiia-dev
by nubiia-dev

create_document

Create invoices, estimates, purchase orders, and similar documents in Holded. Supports drafts and auto-numbering overrides on sales documents.

Instructions

Create a new document (invoice, estimate, purchase, etc.). By default the document is approved (finalized) so it appears in the Holded UI; pass approveDoc:false to create a draft instead. Set the expense/income account at document level via expAccountId (it cascades to all lines); a per-line account is rejected because Holded ignores it. On SALES documents an auto-incrementing numbering series may OVERRIDE the requested invoiceNum — the tool re-reads the created document and returns a _warnings note if that happened. On purchases the supplier number in invoiceNum is preserved. retention (IRPF) is accepted on sales but rejected on purchases (Holded ignores it there).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesDocument date as Unix timestamp
itemsYesArray of line items
notesNoNotes for the document
docTypeYesType of document to create
currencyNoCurrency code (e.g., EUR, USD)
contactIdYesContact ID for the document
retentionNoIRPF retention percentage. Accepted on SALES documents only; rejected on purchases because Holded silently ignores it there.
approveDocNoWhether to immediately approve (finalize) the document instead of saving it as a draft. Defaults to true so the document is visible in the Holded UI. When the Holded API receives no value it defaults to draft, and drafts do not appear in Sales > Invoices, the contact Sales tab or global search. Pass false only when you intentionally want a draft. Note: approved documents are permanently locked by Holded.
invoiceNumNoDocument reference number (e.g. invoice number from supplier)
expAccountIdNoExpense account ID for expense documents
salesChannelIdNoSales channel ID to associate with the document
Behavior5/5

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

With no annotations, the description bears full burden and excels. It discloses default approval, draft behavior, numbering override for sales, preservation for purchases, retention rules, expAccountId cascading, per-line account rejection, and permanent locking of approved documents.

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 a single dense paragraph of five sentences covering many points without wasted words. It could be slightly improved with structure (e.g., bullet points), but it remains efficient and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, multiple behaviors), the description covers all key aspects: approval, numbering, retention, account cascading, and warning mechanism. No gaps are evident for typical use.

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?

Although schema coverage is 100%, the description adds significant value beyond schema descriptions by explaining the practical implications of approveDoc (default behavior, draft visibility), invoiceNum (override warning), retention (accepted/rejected), and expAccountId cascading.

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 clearly states 'Create a new document (invoice, estimate, purchase, etc.)' with a specific verb and resource. It lists the docType enum values, covering all document types, and distinguishes itself from sibling tools like update_document and delete_document.

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 provides explicit guidance on when to use approveDoc:false for drafts, explains numbering behavior for sales vs purchases, and notes retention acceptance/rejection. While it doesn't directly compare to alternatives, the context is clear enough for most use cases.

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/nubiia-dev/mcp-holded'

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