Skip to main content
Glama
almostnine

Fatture in Cloud MCP

by almostnine
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Elenco documenti emessi

fic_list_issued_documents
Read-onlyIdempotent

List issued invoices, credit notes, quotes, and other documents with filters by period, client, number, payment status, and SDI status to track receivables and e-invoice progress.

Instructions

Elenca fatture, note di credito, proforma, preventivi, ordini, DDT e gli altri documenti emessi, con filtri per periodo, cliente, numero, stato di pagamento e stato SDI. Per ogni documento: numero, data, cliente, importi, stato di pagamento, importo da incassare e scaduto, stato della fattura elettronica. Esempi: "fatture di ottobre 2026" -> {type:"invoice", year:2026, month:10}; "note di credito del 2026" -> {type:"credit_note", year:2026}; "fatture non pagate di Rossi" -> {client_name:"Rossi", payment_status:"not_paid"}. Per le singole rate usa fic_list_installments; per il dettaglio di un documento fic_get_issued_document. Lists issued documents (invoices, credit notes, quotes...) with filters, pagination and payment status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPagina da leggere (da 1).
sortNoOrdinamento; il segno meno indica decrescente.-date
typeNoTipo di documento emesso: invoice (fattura), credit_note (nota di credito), proforma, quote (preventivo), order (ordine), delivery_note (DDT), receipt (ricevuta), work_report (rapportino), supplier_order (ordine a fornitore), self_own_invoice / self_supplier_invoice (autofatture).invoice
yearNoAnno, per esempio 2026.
monthNoMese 1-12; senza anno vale l’anno corrente.
numberNoNumero del documento.
date_toNoData finale inclusa (YYYY-MM-DD). Prevale su anno e mese.
per_pageNoElementi per pagina, massimo 100.
all_pagesNoLegge tutte le pagine (fino al tetto FIC_MAX_PAGES) invece di una sola. Più lento, consuma più richieste.
client_idNoID del cliente in Fatture in Cloud.
date_fromNoData iniziale inclusa (YYYY-MM-DD). Prevale su anno e mese.
ei_statusNoFiltra per stato SDI (not_sent, sent, accepted, rejected, discarded, error...). Attiva la lettura di tutte le pagine.
numerationNoSezionale, per esempio "/A".
client_nameNoParte del nome del cliente.
payment_statusNoFiltra per stato di pagamento; overdue = almeno una rata scaduta e non pagata. Attiva la lettura di tutte le pagine.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description goes beyond them by disclosing the per-document return payload (numero, data, cliente, importi, stato di pagamento, importo da incassare/scaduto, stato fattura elettronica), which is valuable since no output schema exists. It leaves out the fact that some filters force multi-page reads, but the schema carries that note.

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?

Purpose is front-loaded and the examples are compact and high-signal. The trailing English sentence restates what the Italian text already said, a small redundancy that costs it a point.

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?

For a 15-parameter, zero-required, no-output-schema list tool, the description covers purpose, filter dimensions, returned fields, sibling routing, and usage examples. Nothing essential for correct invocation is missing given the 100% schema coverage.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds real value on top by giving concrete natural-language-to-parameter mappings ('fatture di ottobre 2026' -> {type:'invoice', year:2026, month:10}), which clarifies how the free-form filter params combine in practice.

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+resource (list issued documents) and enumerates the document types covered, exactly matching the sibling fic_list_received_documents as its counterpart. It also explicitly names fic_get_issued_document as the single-document variant, so an agent can separate list from detail without opening either 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 routes to alternatives with conditions: 'Per le singole rate usa fic_list_installments; per il dettaglio di un documento fic_get_issued_document.' The worked examples additionally show which filter combinations to use for common natural-language requests, leaving little to inference.

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