ANAF e-Factura

ANAF e-Factura MCP server

Read the invoices your company sent and received through Romania's e-Factura, check ANAF's seal on them, and file invoices and e-Transport declarations with ANAF, from your AI assistant. It also validates, renders and writes invoices, and looks companies up in ANAF's VAT registry. Its three money tools (upload_invoice, upload_invoice_b2c, etransport_file) file a document that cannot be withdrawn: your client asks you before each call, and each goes to ANAF's test environment unless you say otherwise.

You need an OAuth application registered with ANAF (its client id, secret and callback URL), the company's CIF, and a person with a qualified digital certificate and SPV rights for the company, who signs in once in a browser. The server then renews the grant itself, and its --health check warns two weeks before it would need that person again. Validating, rendering, building and reading an invoice, checking a seal and looking up a company need no account.

What you can ask

• "Which invoices did suppliers send us in the last two weeks?"
• "Download the newest invoice we received, check ANAF's seal on it, and list its lines."
• "Is RO87654329 a VAT payer, and does it apply VAT on collection?"
• "Invoice Client SRL for 10 hours of consulting at 500 RON an hour plus 21% VAT, have ANAF validate it, and file it in the test environment."
• "How many days are left on our ANAF authorization?"

Install

With Claude Code:

claude mcp add anaf-efactura -e ANAF_CONFIG="<path to ANAF app.json>" -- npx -y @foreverworks/mcp-anaf-efactura

Claude Desktop (Settings, Developer, Edit Config) and most other clients read the same command as JSON:

{

"mcpServers": { "anaf-efactura": { "command": "npx", "args": ["-y", "@foreverworks/mcp-anaf-efactura"], "env": { "ANAF_CONFIG": " " } } } }

Each runs the published package on Node 22.19 or newer. VS Code and the Claude Desktop bundle ask for ANAF_CONFIG as they add the server. Cursor reads it from your environment instead (${env:ANAF_CONFIG}), so set it before you start Cursor. Configuration says what it holds.

From a clone

git clone https://github.com/foreverworks/mcps.git && cd mcps

npm ci && npm run build claude mcp add anaf-efactura -e ANAF_CONFIG=" " -- node "$PWD/servers/anaf-efactura/dist/index.js"

In a JSON configuration, the command is node and its one argument the full path of servers/anaf-efactura/dist/index.js. To share one running copy between several clients over HTTP, see docs/deploying.md.

Configuration

app.json holds the application you register with ANAF (below):

{

"app_name": " ", "client_id": " ", "client_secret": " ", "redirect_uris": [" "], "company_cif": " " }

client_id and client_secret are required, and authorizing needs redirect_uris. company_cif (or cif) is the company a call acts on when it names none; one grant can cover several companies, so a cif argument overrides it. endpoints overrides ANAF's URLs by name (authorize, token, hello, fctelProd, fctelTest, etransportProd, etransportTest), and api_base / api_test_base the e-Factura bases. The server never writes app.json, and its errors name a bad field, never a value. Without ANAF_CONFIG the server still starts, and the tools that need no grant work.

Getting the client id and secret

ANAF calls this registering an application in an OAuth profile; its procedure, Oauth_procedura_inregistrare_aplicatii_portal_ANAF.pdf (in Romanian), shows each screen.

1. Check that the person who will sign in is registered in SPV with their qualified certificate and one of the company's rights: legal representative, designated representative or empowered person (reprezentant legal, reprezentant desemnat, împuternicit).
2. Create a developer account at anaf.ro/InregOauth (Servicii Online, Înregistrare utilizatori, Dezvoltatori aplicații, "Înregistrare pentru API-uri"), new or from a portal account you have, and confirm your e-mail with the "Cod de verificare" ANAF sends.
3. Sign in ("Autentificare utilizator"), open "Editare profil Oauth", then "Gestionare aplicații".
4. Name the application, choose its services (E-Factura, and E-Transport for the e-Transport tools), and give a Callback URL you control, such as https://example.com/anaf/callback; nothing has to answer there. Press "Generare Client ID".
5. Click the application in the list, and copy its Client ID, Client Secret and Callback URL into app.json.

The grant may do only what both the application's services and the certificate holder's SPV rights allow; health shows its roles (EFACTURA, ETRANSPORT).

Files in and out

A document goes in byte for byte, never as text a model retyped, because ANAF's seal covers the exact bytes: by path from the server's file roots (MCP_FILE_ROOTS; over stdio, the client's folders or the working directory), or as { "content_base64": "...", "sha256": "..." } from a script. A link, a file outside the roots, a wrong checksum or a document that is not UTF-8 is refused before anything is sent. A path in the outbox is taken too, so build_invoice's file goes straight to validate_invoice and upload_invoice.

Files come out into the outbox at mode 0640, whole or not at all, and never over a file holding other bytes (that one gets the next numbered name, such as 5001-2.zip); a save_dir must be a folder inside it. The state dir holds tokens.json, authorization.json and uploads.json at 0600. Neither the state dir nor the outbox may sit inside app.json's directory. The variables every server shares are in docs/configuration.md.

First run

The tools that read or file at ANAF need a grant, which only the certificate holder can give. Ask your assistant to authorize the server with ANAF:

1. `begin_authorization` answers ANAF's sign-in page for your application (authorizeUrl), open for 30 minutes; redirect_uri picks one of several callback URLs. A client that shows links itself (MCP URL elicitation: over stdio, or over HTTP with a client of protocol 2026-07-28, as Claude Code is) offers you the page; if you do not hold the certificate, decline and pass the address on.
2. The certificate holder opens it in the browser where the certificate is installed, picks the certificate, and signs in.
3. The browser lands on the callback URL, with ?code=...&state=... in the address. The page may fail to load; the address is what counts.
4. Pass that whole address to `complete_authorization` (`redirect_url`) at once: ANAF's code dies 60 seconds after it is issued. The server checks the state, exchanges the code, writes tokens.json, and answers only the two expiry dates; no token reaches the conversation.
5. Ask for `health`: the grant's roles and the days left on each token.

Keeping the grant alive

ANAF's procedure (pp. 28 and 33) gives the access token 90 days (or the exp it states) and the refresh token 365. A call within 3 days of the access token's end refreshes it first (refresh_token with force refreshes now), and each refresh brings a refresh token good for another 365 days. If the refresh token runs out or ANAF refuses it (invalid_grant), only the certificate holder can bring the grant back, by repeating the steps above. For a server used rarely, refresh daily from a timer. From a clone, in servers/anaf-efactura:

node dist/index.js --health            # greet ANAF with the stored token; the days left

node dist/index.js --refresh # refresh when the access token has under 14 days left node dist/index.js --refresh --force # refresh now

Each prints one ANAF: OK|WARN|FAIL ... line, never a token, and exits 0 for OK, 1 for FAIL (a person has to act: a dead grant, a broken configuration) or 2 for WARN (ANAF unwell, or the refresh token ends within 14 days).

Tools

read changes nothing at ANAF (some save files to the outbox); write changes the stored grant; money files a document with ANAF, and your client asks you before each call.

| upload_invoice_b2c | money | Files an invoice to a person t