Skip to main content
Glama

Alegra: Create invoice

alegra_create_invoice

Alegra: Create a sales invoice for a contact as a draft or an open invoice. Creates a sales invoice with one or more lines and returns its ID, number, totals and status. With status draft nothing is issued and the invoice can still be edited in Alegra. With status open the invoice is saved as open, and with generate_stamp true Alegra also tries to stamp it with your tax authority; if stamping fails, the invoice stays a draft and the error is returned. The invoice is not emailed: use email_invoice for that. If you give no number_template_id, Alegra uses your preferred numbering. By default you confirm each call; you can switch that off for this tool. Reaches other people: confirm with the user before each call. Needs the user's Cotlet API key with access to this app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesInvoice date, YYYY-MM-DD.
itemsYesLines of the invoice. Each line has item_id from list_items, quantity and price, plus optional discount in percent without the % sign and tax_ids.
statusNodraft or open. Default: draft when nothing is paid.
due_dateYesDue date, YYYY-MM-DD.
contact_idYesClient contact ID from list_contacts.
generate_stampNotrue asks Alegra to stamp the invoice with your tax authority where your country requires it. Default: false.
number_template_idNoNumbering to use. Default: your preferred numbering.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only give the safety profile (readOnly=false, openWorld=true, destructive=false). The description adds rich behavior beyond that: draft issues nothing and stays editable, open persists as open, stamping failure reverts to draft and returns the error, confirmation defaults and can be toggled, and a Cotlet API key with app access is required.

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?

Front-loaded with purpose and mode semantics, then operational details. Slightly long and the confirmation guidance is stated twice ('you confirm each call' and 'confirm with the user before each call'), a minor redundancy, but every other sentence earns its place.

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?

With no output schema, the description still names the return values (ID, number, totals, status) and covers the critical mutation risks, auth requirements, and side effects. An agent has everything needed to call this correctly and safely.

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 seven parameters (including status enum, date formats, item line structure, number_template_id default) are already documented in the schema. The description reinforces the status and numbering semantics but adds little parameter meaning beyond what the schema carries, so the baseline 3 applies.

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 sales invoice for a contact') and immediately bounds scope with the draft/open distinction. It also names the sibling to use for a related need ('not emailed: use email_invoice'), letting an agent disambiguate without opening a schema.

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

Usage Guidelines5/5

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

Explicitly describes when to choose draft vs open vs generate_stamp, states the fallback when stamping fails, and routes emailing to email_invoice. Nothing about tool selection is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources