Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Facture Électronique France

PYPI · MCP-FACTURE-ELECTRONIQUE-FR · SCANNED SEP 20

MCP server for French e-invoicing (XP Z12-013). Manages invoices, validation and compliance.

Available components

pypi · mcp-facture-electronique-fr 82
0 this week 82 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
  • 2 of 29 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency48
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
  • Clear OSI-approved license (Apache-2.0).Pass
  • Actively maintained (last published 7 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability66
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 8710 tokens (~256/item across 34 items; 34 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
  • No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety75
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • 0 of 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "delete_directory_line" implies "delete" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
  • An AI judge read all 35 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass
Install

How do I install the Facture Électronique France MCP server?

Facture Électronique France runs locally as a PyPI package, launched with uvx mcp-facture-electronique-fr. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · mcp-facture-electronique-fr

# add to Claude Code
claude mcp add cmendezs-mcp-facture-electronique-fr -- uvx mcp-facture-electronique-fr
// .cursor/mcp.json
{
  "mcpServers": {
    "cmendezs-mcp-facture-electronique-fr": {
      "command": "uvx",
      "args": [
        "mcp-facture-electronique-fr"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "cmendezs-mcp-facture-electronique-fr": {
      "command": "uvx",
      "args": [
        "mcp-facture-electronique-fr"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add cmendezs-mcp-facture-electronique-fr -- uvx mcp-facture-electronique-fr
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "cmendezs-mcp-facture-electronique-fr": {
      "type": "local",
      "command": [
        "uvx",
        "mcp-facture-electronique-fr"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add cmendezs-mcp-facture-electronique-fr --command uvx --arg mcp-facture-electronique-fr
# ~/.hermes/config.yaml
mcp_servers:
  cmendezs-mcp-facture-electronique-fr:
    command: "uvx"
    args: ["mcp-facture-electronique-fr"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "cmendezs-mcp-facture-electronique-fr": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "mcp-facture-electronique-fr"
      ]
    }
  }
}
# add to Vellum
assistant mcp add cmendezs-mcp-facture-electronique-fr -t stdio -c uvx -a mcp-facture-electronique-fr
// mcp.json
{
  "mcpServers": {
    "cmendezs-mcp-facture-electronique-fr": {
      "command": "uvx",
      "args": [
        "mcp-facture-electronique-fr"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 20 Sept 26 0
    • Stability: 0.97 → pass security
  • 19 Sept 26 +16
    • Malware scan: unverified → pass ▲ security
  • 18 Sept 26 −15
    • Malware scan: pass → unverified ▼ security
  • 17 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

  • 15 Sept 26 +16
    • Malware scan: unverified → pass ▲ security
  • 14 Sept 26 −18
    • Malware scan: pass → unverified ▼ security
    • Stability: pass → 0.80 functional
  • 13 Sept 26 +42
    • Injection markers: unverified → pass ▲ security
    • Stability: unverified → pass ▲ security
    • Tool coverage: unverified → 100 ▲ functional
    • MCP protocol: unverified → pass ▲ functional
  • 12 Sept 26 −27
    • Stability: pass → unverified ▼ security
    • Tool safety: pass → unverified ▼ security
    • Malware scan: unverified → pass ▲ security
    • Capabilities: pass → unverified ▼ functional
    • Tool coverage: 100 → unverified ▼ functional
    • Schema quality: Schema quality not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet. functional
    • Stability: pass → 0.97 functional
    • Package version: 0.9.0 → 0.9.1 functional
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 20 Sept 2026 · Analysed pypi/mcp-facture-electronique-fr@0.9.1

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem pypi

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted hatchling.build

Background: Why install scripts are a supply-chain risk →

Dependencies 29 packages
Packages resolved 29
Stale 1
No linked repository 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 34 exposed · ~8,105 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
check_ppf_annuaire_health ~41

Check the availability of the PPF Annuaire service (GET /healthcheck). Use before a directory-management session to ensure the service is reachable.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

create_directory_line ~219

Create a directory line (electronic invoice receiving address) (POST /ligne-annuaire). HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

NameTypeReqDescription
confirmation_token––Confirmation token from a previous call. Omit on the first call.
date_debut_effetstringyesEffective start date, ISO YYYY-MM-DD (dateDebutEffet).
date_fin_effet––Effective end date, ISO YYYY-MM-DD, if known.
identifiant_routage––Routing-code identifier to refine the address.
matricule_plateformestringyes4-digit Approved Platform registration number receiving the invoices.
sirenstringyesSIREN of the taxable entity creating this receiving address.
siret––Specific establishment SIRET. If absent, applies to the whole SIREN.
suffixe_adressage––Addressing suffix (suffixeAdressage).

Structured output declared, but exposes no named fields.

No examples provided.

create_routing_code ~242

Create a routing code (POST /code-routage). HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

NameTypeReqDescription
confirmation_token––Confirmation token from a previous call. Omit on the first call.
etat_administratifstring–'A' (active) or 'F' (closed).
gestion_engagement_juridique––Whether a legal-commitment number (engagement juridique) is mandatory.
identifiant_routagestringyesRouting-code identifier to create (max 100 chars, pattern [-_/@a-zA-Z0-9]).
libelle_code_routagestringyesHuman-readable label for the routing code.
nature_etablissementstringyesWhether the establishment is private or public.
siretstringyesEstablishment SIRET (14 digits) this routing code belongs to.
type_identifiant_routagestringyes4-digit type code for the routing-code identifier (typeIdentifiantRoutage).

Structured output declared, but exposes no named fields.

No examples provided.

create_webhook ~445

Subscribe to webhook notifications from the Approved Platform. The AP will POST event payloads to the callback URL whenever a flow matching the specified filters (flow type, direction, processing rule, ack status) is created or updated. HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

NameTypeReqDescription
ack_status––Optional acknowledgement status filter: Pending, Ok, Error.
auth_client_id––Client ID for OAUTH2 authentication on the callback.
auth_client_secret––Client secret for OAUTH2 authentication on the callback.
auth_token_url––Token URL for OAUTH2 authentication on the callback.
auth_type––Authentication type for the callback: BASIC or OAUTH2.
auth_user_id––User ID for BASIC authentication on the callback URL.
auth_user_password––Password for BASIC authentication on the callback URL.
callback_urlstringyesURL the Approved Platform will POST notifications to. Must be HTTPS and reachable from the AP network.
confirmation_token––Confirmation token from a previous call. Omit on the first call; supply on the second call to execute.
flow_directionstringyesDirection filter: 'In' for incoming flows (from PDP to OD), 'Out' for outgoing flows (from OD to PDP).
flow_typestringyesFlow type to subscribe to: CustomerInvoice, SupplierInvoice, CustomerInvoiceLC, SupplierInvoiceLC, AggregatedCustomerTransactionReport, UnitaryCustomerTransactionReport, AggregatedCustomerPaymentRepo…
processing_rule––Optional processing rule filter: B2B, B2BInt, B2C, B2G, etc.
signature_algo––Signature algorithm: RS256, HS256, ECDSA, EDDSA_25519, RSA_PSS, EDDSA_448.
signature_key––Base64-encoded signing key for webhook payload verification.

Structured output declared, but exposes no named fields.

No examples provided.

delete_directory_line ~125

Delete a directory line (DELETE /ligne-annuaire/id-instance:{id-instance}). HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

NameTypeReqDescription
confirmation_token––Confirmation token from a previous call. Omit on the first call.
id_instancestringyesDirectory instance ID (idInstance) of the directory line to delete. WARNING: this action is permanent. After deletion, senders will no longer be able to send invoices via this address.

Structured output declared, but exposes no named fields.

No examples provided.

delete_webhook ~109

Delete (unsubscribe from) a webhook. After deletion, the AP will stop sending notifications to the callback URL. HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

NameTypeReqDescription
confirmation_token––Confirmation token from a previous call. Omit on the first call; supply on the second call to execute.
webhook_uidstringyesUUID of the webhook subscription to delete.

Structured output declared, but exposes no named fields.

No examples provided.

get_company_by_id_instance ~56

Look up a legal unit by directory instance ID (GET /siren/id-instance:{id-instance}).

NameTypeReqDescription
id_instancestringyesDirectory instance ID (idInstance) of the legal unit, from a previous search.

Structured output declared, but exposes no named fields.

No examples provided.

get_company_by_siren ~51

Look up a legal unit by SIREN (GET /siren/code-insee:{siren}).

NameTypeReqDescription
sirenstringyesExact SIREN (9 digits, no spaces).

Structured output declared, but exposes no named fields.

No examples provided.

get_directory_line ~50

Look up a directory line by directory instance ID (GET /ligne-annuaire/id-instance:{id-instance}).

NameTypeReqDescription
id_instancestringyesDirectory instance ID (idInstance) of the directory line.

Structured output declared, but exposes no named fields.

No examples provided.

get_directory_line_by_code ~53

Look up a directory line by addressing code (GET /ligne-annuaire/code:{identifiant-adressage}).

NameTypeReqDescription
identifiant_adressagestringyesAddressing identifier (identifiantAdressage).

Structured output declared, but exposes no named fields.

No examples provided.

get_establishment_by_id_instance ~55

Look up an establishment by directory instance ID (GET /siret/id-instance:{id-instance}).

NameTypeReqDescription
id_instancestringyesDirectory instance ID (idInstance) of the establishment, from a previous search.

Structured output declared, but exposes no named fields.

No examples provided.

get_establishment_by_siret ~51

Look up an establishment by SIRET (GET /siret/code-insee:{siret}).

NameTypeReqDescription
siretstringyesExact SIRET (14 digits, no spaces).

Structured output declared, but exposes no named fields.

No examples provided.

get_flow ~153

Retrieve a flow by its identifier. docType allows choosing between JSON metadata (Metadata), the original document (Original), the converted document (Converted), or the readable representation (ReadableView). By default, returns the JSON metadata (status, dates, identifiers).

NameTypeReqDescription
doc_typestring–Document type to retrieve: Metadata (default, returns the flow's JSON metadata — recommended), Original (original submitted document, returned as base64), Converted (document converted by the AP, ret…
flow_idstringyesFlow identifier assigned by the Approved Platform (returned by submit_flow or search_flows, maxLength 36).

Structured output declared, but exposes no named fields.

No examples provided.

get_routing_code_by_id_instance ~55

Look up a routing code by directory instance ID (GET /code-routage/id-instance:{id-instance}).

NameTypeReqDescription
id_instancestringyesDirectory instance ID (idInstance) of the routing code.

Structured output declared, but exposes no named fields.

No examples provided.

get_routing_code_by_siret_and_code ~84

Look up a routing code by SIRET and code (GET /code-routage/siret:{siret}/code:{identifiant-routage}).

NameTypeReqDescription
identifiant_routagestringyesRouting-code identifier (identifiantRoutage).
siretstringyesEstablishment SIRET (14 digits).

Structured output declared, but exposes no named fields.

No examples provided.

get_webhook ~57

Retrieve the full details of a webhook subscription: callback URL, authentication mode, signature configuration, and metadata filters (flow type, direction, processing rule, ack status).

NameTypeReqDescription
webhook_uidstringyesUUID of the webhook subscription to retrieve.

Structured output declared, but exposes no named fields.

No examples provided.

healthcheck_flow ~47

Check the availability of the Approved Platform's Flow Service. Returns the operational status of the service (ok/degraded/unavailable). Use before an invoice submission session to ensure the AP is reachable.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

list_webhooks ~53

List all webhook subscription IDs owned by the current OAuth2 token holder. Returns a list of webhook UUIDs. Use get_webhook with each ID to retrieve the full subscription details (callback URL, filters, authentication).

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

replace_directory_line ~133

Fully replace a directory line (PUT /ligne-annuaire/id-instance:{id-instance}). HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

NameTypeReqDescription
confirmation_token––Confirmation token from a previous call. Omit on the first call.
date_fin_effet––Effective end date, ISO YYYY-MM-DD, if any.
id_instancestringyesDirectory instance ID (idInstance) of the directory line.
matricule_plateformestringyesApproved Platform registration number.

Structured output declared, but exposes no named fields.

No examples provided.

replace_routing_code ~184

Fully replace a routing code (PUT /code-routage/id-instance:{id-instance}). Unlike update_routing_code, all fields are required and replace the existing object entirely. HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

NameTypeReqDescription
confirmation_token––Confirmation token from a previous call. Omit on the first call.
etat_administratifstringyes'A' (active) or 'F' (closed).
id_instancestringyesDirectory instance ID (idInstance) of the routing code.
libelle_code_routagestringyesLabel for the routing code.
type_identifiant_routagestringyes4-digit type code (typeIdentifiantRoutage).

Structured output declared, but exposes no named fields.

No examples provided.

search_company ~174

Search legal units (SIRENs) in the PPF Annuaire (POST /siren/recherche). A company must appear here before its establishments (SIRETs) or directory lines (ligne-annuaire) can be resolved. Prefer get_company_by_siren when the exact SIREN is already known.

NameTypeReqDescription
etat_administratif––Administrative status filter (etatAdministratif).
ignorerinteger–Number of results to skip for pagination (ignorer).
limiteinteger–Maximum number of results (limite).
raison_sociale––Legal/trade name (partial match). Use when the SIREN is unknown.
siren––Exact SIREN (9 digits, no spaces).
type_entite––Entity type filter (typeEntite).

Structured output declared, but exposes no named fields.

No examples provided.

search_directory_line ~149

Search directory lines (electronic invoice receiving addresses) (POST /ligne-annuaire/recherche). Call before sending an invoice to verify the recipient has a registered line and to identify their Approved Platform.

NameTypeReqDescription
identifiant_adressage––Exact addressing identifier (identifiantAdressage).
identifiant_routage––Routing-code identifier.
ignorerinteger–Number of results to skip for pagination (ignorer).
limiteinteger–Maximum number of results (limite).
matricule_plateforme––4-digit Approved Platform registration number.
siren––SIREN (9 digits).
siret––SIRET (14 digits).

Structured output declared, but exposes no named fields.

No examples provided.

search_establishment ~122

Search establishments (SIRETs) in the PPF Annuaire (POST /siret/recherche).

NameTypeReqDescription
denomination––Establishment name (partial match).
etat_administratif––Administrative status filter (etatAdministratif).
ignorerinteger–Number of results to skip for pagination (ignorer).
limiteinteger–Maximum number of results (limite).
siren––Parent SIREN (9 digits). Lists all establishments.
siret––Exact SIRET (14 digits, no spaces).

Structured output declared, but exposes no named fields.

No examples provided.

search_flows ~268

Search flows (invoices, statuses, e-reportings) in the Approved Platform by criteria: flow type, status, processingRule, period, trackingId. Pagination via updatedAfter: use the 'nextUpdatedAfter' field from the response as the updated_after parameter value to get the next page.

NameTypeReqDescription
flow_type––Filter by flow type: Invoice, CreditNote, EReportingB2B, EReportingB2C, LifecycleStatus, etc.
limitinteger–Maximum number of flows to return (1-500, default 50).
processing_rule––Filter by processing rule: B2B, B2BInt, B2C, OutOfScope, ArchiveOnly, NotApplicable.
status––Filter by flow status. Examples: Deposited, Processing, Delivered, Rejected, Approved, Refused. Refer to the AP documentation for the complete list.
tracking_id––Filter by trackingId (sender free-form identifier, maxLength 36).
updated_after––Pagination: only return flows updated after this date/time (ISO 8601 format, e.g. 2024-09-01T00:00:00Z). Use the 'nextUpdatedAfter' value from the previous response to paginate.

Structured output declared, but exposes no named fields.

No examples provided.

search_routing_code ~125

Search routing codes (POST /code-routage/recherche).

NameTypeReqDescription
etat_administratif––'A' (active) or 'F' (closed).
identifiant_routage––Exact routing-code identifier (identifiantRoutage).
ignorerinteger–Number of results to skip for pagination (ignorer).
libelle_code_routage––Routing code label (partial match).
limiteinteger–Maximum number of results (limite).
siret––Establishment SIRET (14 digits).

Structured output declared, but exposes no named fields.

No examples provided.

submit_flow ~935

Submit an electronic invoice, e-reporting, or lifecycle status to the Approved Platform. Scope: Compatible Solution (CS) mode, no payload validation. See README "Scope" section. This is the primary action for sending B2B invoices (Factur-X, UBL, CII), B2BInt/B2C e-reportings, or CDAR lifecycle status messages. HUMAN-IN-THE-LOOP: This tool requires explicit user confirmation. Call without confirmation_token first; show the returned summary to the user; then call again with the provided token to execute the submission. BEHAVIOR: - Submission is asynchronous: the AP returns a flowId and an initial status (typically 'Deposited'), not the final delivery status. Poll get_flow(flow_id) or search_flows to track processing. - Returns an error dict (with 'error' key) if the base64 encoding is invalid. - The AP may reject the flow synchronously (e.g. malformed XML, unknown recipient, quota exceeded); in that case the response contains an error code and message. - If processing_rule is B2B, the recipient must be registered in the PPF directory with an active directory line; verify with get_directory_line before submitting. RESPONSE on success: includes flowId (AP-assigned identifier), trackingId (echoed back), status (initial processing status), and submittedAt timestamp. USAGE GUIDELINES: - Always call get_directory_line (or search_directory_line) first to confirm the recipient is reachable and to identify their Approved Platform before submitting a B2B invoice. - Set a meaningful tracking_id (invoice number or UUID) to simplify later retrieval via search_flows. - After submission, use get_flow(flow_id, doc_type='Metadata') to monitor the flow status. - For lifecycle statuses on received invoices (Refused, Approved, etc.), prefer submit_lifecycle_status which provides structured status fields and handles mandatory PPF transmissions. - Call healthcheck_flow before a batch submission to confirm the AP is available.

NameTypeReqDescription
confirmation_token––Confirmation token returned by a previous call to this tool. Required to actually submit; omit on the first call to receive a summary and token for user approval.
file_base64stringyesFile content encoded in base64. Accepted formats: Factur-X (PDF/A-3 with embedded XML), UBL 2.1 (XML), UN/CEFACT CII D22B (XML). Maximum file size is defined by the Approved Platform (typically a few…
file_namestringyesFile name with extension (e.g. 'invoice_2024_001.xml', 'invoice_2024_001.pdf'). The AP uses the extension to detect the format when flow_syntax is ambiguous.
flow_syntaxstringyesSyntax/format of the submitted file (required). Common values: FacturX — PDF/A-3 with embedded Factur-X XML; UBL — UBL 2.1 XML invoice or credit note; CII — UN/CEFACT CII D22B XML invoice; CDAR — XML…
flow_typestringyesBusiness type of the submitted flow. Common values: Invoice, CreditNote, DebitNote, EReportingB2B, EReportingB2C, LifecycleStatus. Refer to your Approved Platform's documentation for the exhaustive l…
processing_rulestringyesProcessing rule that determines routing and PPF transmission obligations. B2B: domestic invoice between French VAT-registered entities (routed + reported to PPF). B2BInt: international invoice or cro…
tracking_id––Sender-assigned tracking identifier (free-form, maxLength 36). Recommended: use the invoice number or an internal UUID. Allows retrieving this specific flow later via search_flows(tracking_id=...).

Structured output declared, but exposes no named fields.

No examples provided.

submit_lifecycle_status ~936

Emit a processing status on a received invoice: Refused, Approved, PartiallyApproved, Disputed, Suspended, Cashed, PaymentTransmitted, Cancelled. Refused and Cashed are mandatory transmissions to PPF. Reason is mandatory for Refused, Disputed, PartiallyApproved, and Suspended. Builds a real CDAR (CrossDomainAcknowledgementAndResponse, XP Z12-014 v1.4) document — see mcp_facture_electronique_fr.clients.flow_client for the MDT-* field mapping this depends on. HUMAN-IN-THE-LOOP: Requires user confirmation. Call without confirmation_token first, show the summary to the user, then call again with the token.

NameTypeReqDescription
confirmation_token––Confirmation token from a previous call. Omit on the first call; supply on the second call to execute.
currencystring–ISO 4217 currency code for payment_amount (default EUR).
included_note––Free-text note (CDAR IncludedNote/Content) per the bundled Rejetee worked example.
invoice_idstringyesBT-1 invoice number of the referenced invoice (CDAR MDT-87).
invoice_issue_datestringyesBT-2 invoice date, ISO 8601 (YYYY-MM-DD) (CDAR MDT-100).
invoice_type_codestring–BT-3 invoice type code (CDAR MDT-91, default '380' = Invoice).
issuer_party_idstringyesGlobalID (e.g. SIREN) of the party emitting this status — you or the counterparty, whichever this MCP server acts on behalf of (CDAR MDT-38).
issuer_party_namestringyesName of the emitting party (CDAR MDT-39).
issuer_role_codestringyesRole of the emitting party: SE (seller) or BY (buyer) (CDAR MDT-40).
party_id_schemestring–schemeID attribute shared by both party GlobalIDs (default '0002' = SIRENE, per every bundled AFNOR worked example).
payment_amount––Payment amount (decimal string, e.g. '1250.00'). Provided for Cashed and PaymentTransmitted statuses.
payment_date––Payment date (ISO 8601 format: YYYY-MM-DD). Provided for Cashed and PaymentTransmitted statuses.
reason––Status reason (CDAR MDT-114), mandatory per XP Z12-014 Annex A for Refused, Disputed, PartiallyApproved, and Suspended. Free text.
reason_code––Coded reason (CDAR MDT-113) from the per-status motif list in XP Z12-014 Annex A 'Tableau des motifs de STATUTS' (e.g. TX_TVA_ERR, DOUBLON). Not validated against that list.
receipt_datetime––Original receipt timestamp of the referenced invoice, ISO 8601 (CDAR MDT-95). Defaults to the current time if omitted — supply the real value when known for an accurate audit trail.
recipient_party_idstringyesGlobalID of the counterparty receiving this status (CDAR MDT-57).
recipient_party_namestringyesName of the counterparty (CDAR MDT-58).
recipient_role_codestringyesRole of the counterparty — opposite of issuer_role_code (CDAR MDT-59).
recipient_uri––Counterparty's electronic address on the CEF network, if known (CDAR MDT-73).
referenced_flow_idstringyesIdentifier of the invoice flow to which this status applies (flowId returned upon receipt, maxLength 36). Used only for the platform's own flow tracking (flowInfo.trackingId) — not part of the CDAR d…
requested_action––Free-text requested action (CDAR MDT-122).
requested_action_code––Coded requested action (CDAR MDT-121), e.g. 'CNF' ('Créer un Avoir total') per the bundled En_litige worked example. Typically used with Disputed.
status_codestringyesLifecycle status code to emit. Values defined in XP Z12-014 v1.4 (June 2026): Refused (transmitted to PPF), Approved, PartiallyApproved, Disputed, Suspended, Cashed (transmitted to PPF), PaymentTrans…

Structured output declared, but exposes no named fields.

No examples provided.

submit_payment_report ~799

Submit a DGFiP Flux 10.2 / 10.4 payment e-reporting flow. Scope: Compatible Solution (CS) mode, no payload validation. See README "Scope" section. Builds a FRR XML payload conforming to DGFiP Spécifications Externes v3.2 (payment.xsd / ereporting.xsd) and submits it to the Approved Platform via POST /v1/flows with flowSyntax="FRR". Use for: - International B2B payment reporting (processing_rule=B2BInt, flow_type=UnitaryCustomerPaymentReport) - B2C individual payment reporting (processing_rule=B2C, flow_type=UnitaryCustomerPaymentReport) - Aggregated B2C payment reporting (processing_rule=B2C, flow_type=AggregatedCustomerPaymentReport)

NameTypeReqDescription
confirmation_token––Confirmation token returned by a prior pending response.
flow_typestringyesXP Z12-013 FlowType for this payment report: UnitaryCustomerPaymentReport — Flux 10.2 unit payment AggregatedCustomerPaymentReport — Flux 10.4 aggregated B2C payment
invoices_jsonstringyesJSON array of payment records. Each invoice in the `invoices` JSON list must have: Required fields: invoice_id TT-91 Invoice number (reference to the original invoice) issue_date TT-102…
issue_datetimestringyesTT-3: Transmission creation timestamp, e.g. '20250115T120000+0100'.
issuer_idstringyesTT-13: SIREN or SIRET of the French declarant.
issuer_id_schemestringyesTT-12: ID scheme for issuer: 'SIREN' or 'SIRET'.
issuer_namestringyesTT-14: Legal name of the declarant.
issuer_role_codestringyesTT-15: Issuer role: 'MOA' or 'OD'.
period_endstringyesTT-90: Report period end date (ISO 8601, e.g. '2025-01-31').
period_startstringyesTT-89: Report period start date (ISO 8601, e.g. '2025-01-01').
processing_rulestringyesB2BInt for international B2B payments, B2C for B2C payments.
sender_idstringyesTT-8: Identifier of the CS/PDP platform submitting the report.
sender_id_schemestringyesTT-7: ID scheme for sender, e.g. 'SIREN', 'SIRET'.
sender_namestringyesTT-9: Legal name of the sender platform.
sender_role_codestringyesTT-10: Sender role code: 'CS', 'PDP', 'OD', or 'MOA'.
tracking_id––Optional external tracking identifier for this flow.
transmission_idstringyesTT-1: Unique identifier for this transmission (generated by sender).
transmission_name––TT-2: Optional human-readable name for the transmission.
type_codestringyesTT-4: Transmission type code, e.g. '380'.

Structured output declared, but exposes no named fields.

No examples provided.

submit_transaction_report ~1,468

Submit a DGFiP Flux 10.1 / 10.3 transaction e-reporting flow. Scope: Compatible Solution (CS) mode, no payload validation. See README "Scope" section. Builds a FRR XML payload conforming to DGFiP Spécifications Externes v3.2 (transaction.xsd / ereporting.xsd) and submits it to the Approved Platform via POST /v1/flows with flowSyntax="FRR". Use for: - International B2B outbound sales (processing_rule=B2BInt, flow_type=IndividualCustomerTransactionReport) - International B2B inbound purchases (processing_rule=B2BInt, flow_type=UnitarySupplierTransactionReport) - B2C individual transactions (processing_rule=B2C, flow_type=IndividualCustomerTransactionReport) - Aggregated B2C reports (processing_rule=B2C, flow_type=AggregatedCustomerTransactionReport)

NameTypeReqDescription
confirmation_token––Confirmation token returned by a prior pending response.
flow_typestringyesXP Z12-013 FlowType for this e-reporting submission: IndividualCustomerTransactionReport — Flux 10.1 individual B2C or intl B2B AggregatedCustomerTransactionReport — Flux 10.3 aggregated B2C Un…
invoices_jsonstringyesJSON array of invoice transaction records. Each invoice in the `invoices` JSON list must have: Required fields: id TT-19 Invoice number / identifier issue_date…
issue_datetimestringyesTT-3: Transmission creation timestamp, e.g. '20250115T120000+0100'.
issuer_idstringyesTT-13: SIREN or SIRET of the French taxable entity (déclarant).
issuer_id_schemestringyesTT-12: ID scheme for issuer, typically 'SIREN' or 'SIRET'.
issuer_namestringyesTT-14: Legal name of the declarant.
issuer_role_codestringyesTT-15: Issuer role code. Use 'MOA' (assujetti / declarant) or 'OD' (obligataire délégant).
period_endstringyesTT-18: Report period end date in ISO 8601 format (e.g. '2025-01-31').
period_startstringyesTT-17: Report period start date in ISO 8601 format (e.g. '2025-01-01').
processing_rulestringyesXP Z12-013 ProcessingRule: B2BInt — international B2B e-reporting B2C — B2C e-reporting
sender_idstringyesTT-8: Identifier of the CS/PDP platform submitting the report.
sender_id_schemestringyesTT-7: ID scheme for sender, e.g. 'SIREN', 'SIRET', 'TVA', '0088'.
sender_namestringyesTT-9: Legal name of the sender platform.
sender_role_codestringyesTT-10: Sender role code. Use 'CS' (Compatible Solution), 'PDP', 'OD' (obligataire délégant), or 'MOA' (assujetti).
tracking_id––Optional external tracking identifier for this flow.
transmission_idstringyesTT-1: Unique identifier for this transmission (generated by sender).
transmission_name––TT-2: Optional human-readable name for the transmission.
type_codestringyesTT-4: Transmission type code, e.g. '380' (invoice report).

Structured output declared, but exposes no named fields.

No examples provided.

update_directory_line ~83

Partially update a directory line (PATCH /ligne-annuaire/id-instance:{id-instance}). Only provided fields are modified.

NameTypeReqDescription
date_fin_effet––New effective end date, ISO YYYY-MM-DD.
id_instancestringyesDirectory instance ID (idInstance) of the directory line.
matricule_plateforme––New Approved Platform registration number.

Structured output declared, but exposes no named fields.

No examples provided.

update_routing_code ~112

Partially update a routing code (PATCH /code-routage/id-instance:{id-instance}). Only provided fields are modified.

NameTypeReqDescription
etat_administratif––New status. Omit to leave unchanged.
id_instancestringyesDirectory instance ID (idInstance) of the routing code.
libelle_code_routage––New label. Omit to leave unchanged.
type_identifiant_routage––New 4-digit type code. Omit to leave unchanged.

Structured output declared, but exposes no named fields.

No examples provided.

update_webhook ~172

Update a webhook subscription's technical parameters (authentication, signature, custom headers). Metadata filters (flow type, direction) cannot be changed; delete and recreate the webhook instead. Only provided fields are modified (PATCH semantics).

NameTypeReqDescription
auth_client_id––Client ID for OAUTH2 authentication.
auth_client_secret––Client secret for OAUTH2 authentication.
auth_token_url––Token URL for OAUTH2 authentication.
auth_type––New authentication type for the callback: BASIC or OAUTH2.
auth_user_id––User ID for BASIC authentication.
auth_user_password––Password for BASIC authentication.
signature_algo––New signature algorithm.
signature_key––New base64-encoded signing key.
webhook_uidstringyesUUID of the webhook subscription to update.

Structured output declared, but exposes no named fields.

No examples provided.

validate_ereporting_xml ~181

Validate a DGFiP e-reporting (Flux 10) FRR XML payload. Scope: XSD schema validation only, no business-rule checks. See README "Scope" section. Checks the XML against the DGFiP Spécifications Externes v3.2 ereporting.xsd. Returns validation result with errors if any. Use this before submitting to catch structural problems early. Validation levels (in order of preference): - xsd — full schema validation - wellformedness — XML failed to parse (malformed or unsafe input) - none — XSD files not found on disk

NameTypeReqDescription
xml_contentstringyesFRR XML content to validate. Must be a complete Report document per DGFiP Spécifications Externes v3.2 ereporting.xsd.

Structured output declared, but exposes no named fields.

No examples provided.

validate_facturx ~318

Validate a Factur-X CII XML document against its profile's Schematron ruleset. Scope: Schematron (SVRL) business-rule validation only, no XSD structural check. Returns is_valid, errors, and warnings (rule_id, location, text). Use this before embedding the XML into a PDF/A-3 or submitting via submit_flow. Requires the optional `saxonche` extra (FR-XSLT2-1, resolved in mcp-einvoicing-core 1.14.0): the bundled Factur-X 1.09.2 Schematron stylesheets require XSLT 2.0, which lxml/libxslt (XSLT 1.0 only) cannot compile. Install with `pip install mcp-facture-electronique-fr[xslt2]`. If it is missing, this tool returns level="unavailable" with is_valid=None instead of raising.

NameTypeReqDescription
profilestringyesFactur-X profile to validate against. One of: MINIMUM, BASICWL, BASIC, EN16931, EXTENDED, EXTENDED-CTC-FR. EXTENDED-CTC-FR is validated against the generic EXTENDED ruleset only — AFNOR has not publi…
xml_contentstringyesFactur-X CII XML content to validate (the embedded XML, not the PDF/A-3).

Structured output declared, but exposes no named fields.

No examples provided.

Common questions

What is the Facture Électronique France MCP server?

Facture Électronique France is an MCP server listed in the public MCP registry as io.github.cmendezs/mcp-facture-electronique-fr. MCP server for French e-invoicing (XP Z12-013). Manages invoices, validation and compliance. This page covers its PyPI package (mcp-facture-electronique-fr).

Is the Facture Électronique France MCP server safe to use?

Facture Électronique France scores 82 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Facture Électronique France MCP server expose?

Facture Électronique France exposes 34 tools: submit_flow, search_flows, get_flow, submit_lifecycle_status, healthcheck_flow, and 29 more. Their descriptions and schemas cost roughly 8,105 tokens of context every time the server is loaded.

Is the Facture Électronique France MCP server still maintained?

Facture Électronique France is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the Facture Électronique France MCP server under?

Facture Électronique France declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.