FluxMicro

Use this when you need the active FluxMicro organization, its plan and capabilities, MCP permissions, product limits, excluded actions, and useful URLs before deciding the next tool call. invoicing.can_issue_documents and missing_required_for_invoicing say what still blocks issuing an invoice and which update_settings fields fix it. Sales conditions are summarized (sales_conditions_present, sales_conditions_chars), never returned in full. mcp_rules.e_invoicing: this server has no tool to send an e-invoice; issuing an invoice follows the app's rules, e-invoice included.

get_fluxmicro_context

Use this when the user asks for KPIs over a period (Paris days; default: since January 1st). Request level=basic; level=advanced only when capabilities.can_view_advanced_kpis is true (otherwise FEATURE_UNAVAILABLE_FOR_ACCOUNT: say these indicators are not available on this account, without pushing any offer). Under the real regime (basic.urssaf_applicable=false) no URSSAF estimate and no micro-enterprise ceiling are published (null): report 'URSSAF not applicable under the real regime' instead of a number. basic.cash_in is the receipts ledger total excluding VAT with refunds deducted (basic.amount_basis), the same figure as the app; basic.purchases is the purchase register total incl. VAT; basic.net_cash subtracts purchases in the SAME basis as cash_in (basic.net_cash_basis). basic.urssaf_estimate covers social contributions only (no training contribution, no chamber tax, not rounded): for the amount to pay for a period use render_view view=fiscal. basic.amount_due only counts invoices issued in the period that are still awaiting payment, never drafts.

get_kpis

Use this when the user asks which pieces feed a VAT period, why a sale or a purchase is (or is not) in the VAT return, what is still missing before filing, or what was left out on purpose. Returns the VAT journal of one period: each invoice, receipt, credit note, imported charge, purchase or VAT-only entry with its dated events, the rule that dates them, the VAT it brings to that period, what it still misses, the engine's lawful assumptions (e.g. goods delivered on the invoice date), and its state, the same as the app's /tva/ecritures page (state and state_label): valide, a-completer, propose (purchase deductible by default, to confirm in the app), ecartee (left out by the user, or by a rule such as OSS sales or goods invoiced with another EU country's VAT: rule_excluded gives the reason), declaree, reprise or regularisation (from an earlier period), en-attente (invoice awaiting payment), annulee (nothing to declare), apres-depot (added after the return was filed), attente-periode, hors-periode. Paginated: limit (default 25, max 50) and next_cursor; totals cover the whole period. A period key missing from the filing calendar opens the period the app is working on and period_notice says so. READ-ONLY: completing a piece, excluding or re-including it, adding a VAT-only entry and filing the return all happen in the app (see app_url), never here.

get_vat_entries

Use this when the user asks to update FluxMicro organization settings, legal details, payment terms, numbering, or email/design settings when enabled for the account. Only the fields you send change. It stays inside FluxMicro: it never contacts the payment provider itself and never changes the subscription (done by the user in the app); when the company identity changes (legal name, SIREN/SIRET, VAT number, contact, address), FluxMicro refreshes the billing details of the user's own FluxMicro subscription in the background, exactly as the app does. The VAT regime, the IBAN and the online payment link are read-only here. A missing VAT number under the standard regime is reported in warning, not refused; rules for professional clients (late-payment rate, 40 € recovery fee, 60-day terms) are enforced like in the app.

update_settings

Use this when the user asks to record a MANUAL cash-in in the receipts ledger that is not tied to a FluxMicro invoice (including a manual refund entry, direction=refund), or to correct an existing ledger line (id). Invoice payments must go through update_document_state (state=paid) instead, which books the receipt automatically — also calling record_receipt for that payment would double-count the revenue. Lines generated from an invoice or a credit note CAN be corrected here, like in the app: client, reference, payment method, label and notes stay editable; amounts, URSSAF split, direction and inclusion follow the app's locks (frozen once the URSSAF or VAT period is declared; a line linked to an invoice never exceeds what is still due). The cash-in date of a recorded line never changes (omit received_at on an update). For a micro-enterprise, a line split across several URSSAF bases needs a new split (urssaf_basis_kind=mixed) when its net amount changes. VAT: tax_rate_bps/vat_breakdown follow the same rules as the app (rate allowed on the org's territory); vat_item_type (derived from the URSSAF base, checked not chosen), delivered_at (goods, it dates the VAT) and electronic_service (services) only apply to a manual receipt of a VAT-liable organization with the VAT module. Under the real regime URSSAF does not apply and included_in_urssaf cannot be changed. Deleting a ledger line is not possible here: it is done in the app (receipts ledger), which only deletes manual lines. The VAT return itself is filed only in the app at /tva.

record_receipt

Use this when you already have a fluxmicro:// URI and need the targeted entity details, lines, or web/PDF links without listing unrelated data. A receipt or purchase exposes its accounting category, whether a supporting document is attached (boolean only, never the file), its VAT state (proposed, validated, to_complete), its recorded tax_rate_bps and its recorded per-rate vat_breakdown — read that breakdown before correcting the amount of an entry that mixes several rates, and resend it, never a split you made up. A quote or invoice lists its internal attachments (name, size_bytes, created_at): read-only, never sent to the client, the files stay in the app. links.web_url opens that exact quote, invoice or credit note in the app. A receipt also carries urssaf_standing: status outside_declaration means it was noted after its period was declared in FluxMicro and is not in that declaration (relay its note: the declaration is corrected at the Urssaf, then marked "Marquer rectifiee..." in the FluxMicro app when the receipt sheet offers it, never here); other statuses are declared, declared_outside_fluxmicro, to_declare, upcoming, not_counted.

fetch

Use this when you need a compact paginated list or search across clients, products, quotes, invoices, credit notes, receipts, purchases, imported charges, or suppliers. Text search is case-insensitive and matches like the app's lists (document number, client name or exact amount incl. VAT; client name, trade name, email, SIREN, SIRET). Invoice status filters use the displayed status (overdue from the effective due date, paid including invoices settled by credit notes). Documents are filtered on their issue date (creation date while still a draft). Clients carry ca_year_cents (revenue cashed this year) only when the search targets clients alone, null otherwise. Receipts and purchases carry accounting_category (purchases only, null on receipts), has_attachment (whether a supporting document is attached; the file itself is never exposed) and vat_state: proposed (purchase taken as deductible by default, to confirm in the app), validated, or to_complete.

search

Use this when you need to enrich a client or supplier from a French SIREN/SIRET using the public company directory (INSEE SIRENE, an external service). Returns the fields upsert_client accepts (legal_name, trade_name, siren, siret, ape, address, postal_code, city, country). If name_required is true, the directory does not publish the name: ask the user for it, never invent it. Limited like the app: 20 lookups per minute, then a 5-minute pause (RATE_LIMITED). SIRENE_UNAVAILABLE means the directory is down: retry later or let the user type the details.

lookup_company

Use this when the user asks to delete a draft quote or invoice, only while it is still a draft. An issued document is never deleted: an issued invoice is cancelled by a credit note. An old credit note draft can be deleted when it carries no refund receipt and is applied to no invoice.

delete_draft_document

Use this when the user asks to review, archive or annotate a received e-invoice (imported charge), or to mark it paid. Marking it paid needs paid_at AND payment_method (never guess the payment method, ask the user): it books the purchase register AND sends the status "payment sent" (fr:211) to the supplier through the e-invoicing platform, exactly like the app — an effect outside FluxMicro that cannot be undone; never sent for a received credit note. Tell the user before marking it paid. A received invoice already paid or already in the purchase register cannot be marked paid again (ALREADY_PAID): correct its register line with record_purchase. A received invoice the supplier refused can no longer be marked paid.

update_purchase_invoice_state

Use this when the user asks to cancel or refund an issued invoice, fully or partly: a CREDIT NOTE (avoir) is the only way, exactly like the app. Pass source_invoice_id (+ kind refund|credit, + credit_scope). It is ISSUED AND NUMBERED IN THIS CALL (there is no credit note draft and it can never be deleted afterwards), so confirm the invoice, the amount and the kind with the user first. It first settles what the client still owes on that invoice (an unpaid invoice is voided, with nothing to refund); only the already-collected excess is refunded (kind=refund, then record the refund with update_document_state state=paid) or kept as credit for a later invoice (kind=credit, applied with applied_credit_note_id). Its lines and totals are derived from the invoice.

issue_credit_note

Use this when the user asks to issue (émettre) a draft quote or invoice: it receives its number and can no longer be deleted. Credit notes are issued when created by issue_credit_note; an old credit note draft cannot be issued (delete it, then create the credit note again). An invoice goes through the app's VAT issuance check (same engine): it freezes the operation kind, each line's VAT category and territory, the exemption reason and the legal VAT mentions. Refusals use the app's codes: vat_blocking (inconsistent VAT such as a rate under the franchise or outside the territory's rates; blocks every plan) and vat_to_qualify (open VAT question such as a VIES check or the 259 B question; blocks where the VAT sheet exists). The refusal lists the engine's issue and question ids: fix the draft with save_document_draft or ask the user to act in the app; never answer a VAT question or attest a VIES check on the user's behalf. Non-blocking VAT warnings (such as a 0 % line on a sale in France) come back in warning and vat_warnings: relay them to the user.

finalize_document