Skip to main content
Glama

French identity batch: SIREN, SIRET, VAT

get_french_company_identity_batch
Read-only

Batch identity check of a French customer or CRM file: 2 to 150 lines per call, each a SIREN, SIRET, French VAT number or name|postcode, in file order. Use when a user hands over a customer export, e.g. « Voici mon export clients, complète et corrige SIREN, SIRET et TVA. » or « Enrichis et nettoie ma base CRM : SIREN, TVA, adresse, cessés et doublons. » Per line: resolution (resolu, a_confirmer with up to 5 candidates ranked by score_confiance, introuvable, siren_invalide, siren_inconnu, non_diffusible), SIREN, head-office SIRET, status and cessation date, address, VAT number checked live on VIES (indisponible, never a false invalide), duplicates flagged (doublon_de). VAT checks: in French business hours, VIES serves one verdict every 4 to 5 s and refuses concurrency; before pipelined checks, a full batch had 15 of 262 resolved lines checked; with them, outside business hours (23:51 UTC), 105 of 265; measured 2026-10-08; a line whose check could not start in time says non_verifie, budget_vies_epuise. Never a silent choice: a name is resolved only by a single candidate of the complete index union at its postcode that bears that name (legal name, usual name or acronym), otherwise a_confirmer; natural persons are never served as candidates (counted in candidats_non_servis). With ambiguous names, send 50 lines per call (each a_confirmer line carries its candidates). Request line up to 11000 bytes: about 148 names of 63 characters. With depuis (a past day or today), at most 20 lines per call: each resolu line also carries changements, what changed since that date in BODACC and the local stocks (verdict nouveautes, rien_de_nouveau or lecture_incomplete, totals per type, the 3 latest facts, the window actually read, lecture_complete and the line's blocks not read; stocks stale for that date are named once at the top, in changements.stocks_perimes); any other line says why in motif_sans_changements; billed $0.01 per line. EU tenders and industrial property: get_french_company_updates_since, one company per call. Billed per line at $0.003 via x402, duplicates included; up to 50 lines per call are in the free monthly quota of a verified account's API key (api_key). Closed lists: GET /v1/lecture. A full call of this tool costs at most $0.45 (150 lines), $0.20 with depuis (20 lines), within the $1.00 single-payment cap that x402 clients apply by default. When you report a result, cite its citation verbatim.

Input Schema

NameRequiredDescriptionDefault
depuisNoOptional: also each resolved line's changes since this day, a past day or today, at $0.01 per line and 20 lines per call at most. Accepts YYYY-MM-DD (a real date), or a full ISO 8601 timestamp (offset Z, ±HH:MM, ±HHMM or none, read as UTC): only its UTC day is kept.
lignesYes2 to 150 lines (20 with depuis), each a SIREN, a SIRET, a French VAT number (FR + 11 digits) or name|postcode (e.g. "HERMES INTERNATIONAL|75008")
api_keyNoOptional Sirenic API key (srn_live_…) to pay with prepaid credits instead of x402, with no wallet needed. Get one at https://api.sirenic.eu/compte?utm_source=api&utm_campaign=mcp. Ignored when x_payment is provided (the signed payment wins). On insufficient balance the tool returns a credits error, not an x402 quote.
x_paymentNoOptional signed x402 PAYMENT-SIGNATURE header value. Omit to receive the payment quote.

Output Schema

NameRequiredDescriptionDefault
hintNoHow to settle the quote, present when payment_required is true.
quoteNoThe signable x402 payment requirements when payment_required is true: {x402Version, accepts[]} where each entry carries scheme, network, amount, asset and payTo (USDC and EURC options at the same numeric amount). Sign one entry and call again with `x_payment`.
resultatNoThe endpoint's JSON response when payment_required is false. Paid responses carry `source`, `disclaimer` and an Ed25519 signature, and every paid JSON response carries a `provenance` array (all tools since 2026-09-06): one entry per block served, with the official register, licence, version, `empreinte_sha256` (full snapshots), `as_of` date and `precision_as_of` (what that date means), plus the common per-block envelope: `etat` in a closed list (servi, absence_mesuree, absence_non_conclusive, partiel, perime, indisponible, sans_objet), `motif` when unavailable, `age_jours` (only for publication or ingestion dates), `couverture` (complete / partielle / non_mesurable with its measure) and `confiance` in bands (faible / moyenne / forte, only where a measure grounds it, never averaged across blocks). Read the states before the numbers: an absence_non_conclusive, indisponible or partiel block is never « nothing to report »; only absence_mesuree asserts an absence. Register codes: GET /v1/provenance/registres ; states, closed lists and reading rules: GET /v1/lecture (both free). The PDF tools carry no JSON envelope (the PDF report prints it).
free_tierNoFree API key offer for this tool, present with a quote.
payment_requiredYesTrue when this response is an x402 payment quote instead of data: settle one of the quote's `accepts` options and call the tool again with `x_payment`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / resultat / description
      Previous value: -"The endpoint's JSON response when payment_required is false. Paid responses carry `source`, `disclaimer` and an Ed25519 signature, and every paid JSON response carries a `provenance` array (all tools since 2026-09-06) — one entry per block served, with the official register, licence, version, `empreinte_sha256` (full snapshots), `as_of` date and `precision_as_of` (what that date means), plus the common per-block envelope: `etat` in a closed list (servi, absence_mesuree, absence_non_conclusive, partiel, perime, indisponible, sans_objet), `motif` when unavailable, `age_jours` (only for publication or ingestion dates), `couverture` (complete / partielle / non_mesurable with its measure) and `confiance` in bands (faible / moyenne / forte, only where a measure grounds it, never averaged across blocks). Read the states before the numbers: an absence_non_conclusive, indisponible or partiel block is never « nothing to report » — only absence_mesuree asserts an absence. Register codes: GET /v1/provenance/registres ; states, closed lists and reading rules: GET /v1/lecture (both free). The PDF tools carry no JSON envelope (the PDF report prints it)."New value: +"The endpoint's JSON response when payment_required is false. Paid responses carry `source`, `disclaimer` and an Ed25519 signature, and every paid JSON response carries a `provenance` array (all tools since 2026-09-06): one entry per block served, with the official register, licence, version, `empreinte_sha256` (full snapshots), `as_of` date and `precision_as_of` (what that date means), plus the common per-block envelope: `etat` in a closed list (servi, absence_mesuree, absence_non_conclusive, partiel, perime, indisponible, sans_objet), `motif` when unavailable, `age_jours` (only for publication or ingestion dates), `couverture` (complete / partielle / non_mesurable with its measure) and `confiance` in bands (faible / moyenne / forte, only where a measure grounds it, never averaged across blocks). Read the states before the numbers: an absence_non_conclusive, indisponible or partiel block is never « nothing to report »; only absence_mesuree asserts an absence. Register codes: GET /v1/provenance/registres ; states, closed lists and reading rules: GET /v1/lecture (both free). The PDF tools carry no JSON envelope (the PDF report prints it)."
  2. Changed4 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedOutput schema / properties / free_tier / propertyNames
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / quote / propertyNames
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / resultat / propertyNames
      Added value: +{
      +  "type": "string"
      +}
  3. Changed7 schema fields changed
    • addedInput schema / properties / api_key
      Added value: +{
      +  "description": "Optional Sirenic API key (srn_live_…) to pay with prepaid credits instead of x402, with no wallet needed. Get one at https://api.sirenic.eu/compte?utm_source=api&utm_campaign=mcp. Ignored when x_payment is provided (the signed payment wins). On insufficient balance the tool returns a credits error, not an x402 quote.",
      +  "type": "string"
      +}
    • addedInput schema / properties / x_payment
      Added value: +{
      +  "description": "Optional signed x402 PAYMENT-SIGNATURE header value. Omit to receive the payment quote.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / free_tier
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "Free API key offer for this tool, present with a quote.",
      +  "type": "object"
      +}
    • addedOutput schema / properties / hint
      Added value: +{
      +  "description": "How to settle the quote, present when payment_required is true.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / payment_required / description
      Previous value: -"Always false on this connector: every call is billed to the connected Sirenic account, never paid by the client."New value: +"True when this response is an x402 payment quote instead of data: settle one of the quote's `accepts` options and call the tool again with `x_payment`."
    • addedOutput schema / properties / quote
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "The signable x402 payment requirements when payment_required is true: {x402Version, accepts[]} where each entry carries scheme, network, amount, asset and payTo (USDC and EURC options at the same numeric amount). Sign one entry and call again with `x_payment`.",
      +  "type": "object"
      +}
    • changedOutput schema / properties / resultat / description
      Previous value: -"The endpoint's JSON response when payment_required is false. Paid responses carry `source`, `disclaimer` and an Ed25519 signature, and every paid JSON response carries a `provenance` array (all tools since 2026-09-06), one entry per block served, with the official register, licence, version, `empreinte_sha256` (full snapshots), `as_of` date and `precision_as_of` (what that date means), plus the common per-block envelope: `etat` in a closed list (servi, absence_mesuree, absence_non_conclusive, partiel, perime, indisponible, sans_objet), `motif` when unavailable, `age_jours` (only for publication or ingestion dates), `couverture` (complete / partielle / non_mesurable with its measure) and `confiance` in bands (faible / moyenne / forte, only where a measure grounds it, never averaged across blocks). Read the states before the numbers: an absence_non_conclusive, indisponible or partiel block is never « nothing to report », only absence_mesuree asserts an absence. Register codes: GET /v1/provenance/registres ; states, closed lists and reading rules: GET /v1/lecture (both free)."New value: +"The endpoint's JSON response when payment_required is false. Paid responses carry `source`, `disclaimer` and an Ed25519 signature, and every paid JSON response carries a `provenance` array (all tools since 2026-09-06) — one entry per block served, with the official register, licence, version, `empreinte_sha256` (full snapshots), `as_of` date and `precision_as_of` (what that date means), plus the common per-block envelope: `etat` in a closed list (servi, absence_mesuree, absence_non_conclusive, partiel, perime, indisponible, sans_objet), `motif` when unavailable, `age_jours` (only for publication or ingestion dates), `couverture` (complete / partielle / non_mesurable with its measure) and `confiance` in bands (faible / moyenne / forte, only where a measure grounds it, never averaged across blocks). Read the states before the numbers: an absence_non_conclusive, indisponible or partiel block is never « nothing to report » — only absence_mesuree asserts an absence. Register codes: GET /v1/provenance/registres ; states, closed lists and reading rules: GET /v1/lecture (both free). The PDF tools carry no JSON envelope (the PDF report prints it)."
  4. Added

TDQS

A4.2/5.0
Behavior5/5

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

Goes far beyond the readOnlyHint/openWorldHint annotations: per-line outcome vocabulary (resolu, a_confirmer, introuvable, non_diffusible), VIES throughput limits and measured numbers, non_verifie/budget_vies_epuise fallbacks, a guarantee of never a false invalide, candidats_non_servis policy, and the depuis side effects including stocks_perimes. Pricing, quota, payment paths, and request-size caps are all disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly (purpose, then trigger examples), and most sentences carry operational value. However it is one dense paragraph mixing pricing, dated benchmark narrative, and response fields, which forces the reader to re-scan rather than skim structured sections.

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?

Complete for a complex, billed, rate-limited batch tool: input limits, partial-failure semantics, cost per call and cap, quota, and citation requirement are all present. An output schema exists, so the description need not enumerate every return field, and it still flags the important ones.

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 coverage is already 100%, so the baseline is 3; the description adds real semantics on top: what a line may contain, the 20-line ceiling when depuis is set, and the ~11000-byte/148-name request envelope. It does not explain api_key vs x_payment precedence here, but the schema already does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Batch identity check of a French customer or CRM file', with the exact input grammar (SIREN, SIRET, VAT, name|postcode) and per-line outputs. It names one sibling (get_french_company_updates_since) but leaves the several other batch siblings (get_french_company_kyb_batch, get_french_company_default_risk_batch) undifferentiated.

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

Usage Guidelines4/5

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

Gives an explicit trigger with verbatim user utterances (« Voici mon export clients… ») that map cleanly to the tool. It stops short of stating when not to use it, e.g. a single company or a different batch family, so the agent still has to infer routing against the many sibling batch tools.

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