Skip to main content
Glama
AgentIA1984-cmd

fr-compliance-mcp

by AgentIA1984-cmd
OverviewSchemaSourceRelated ServersScoreDiscussions
TypeScript
Remote

fr-compliance-mcp

MCPize

Serveur MCP (Model Context Protocol) de conformite et de KYC France : validation de TVA intracommunautaire, annonces legales BODACC, procedures collectives et score de risque entreprise.

100 % open data (VIES, BODACC/DILA, Etalab) - gratuit, sans cle d'API, sans inscription.

Outils exposes

Outil

Description

fr_vat_compute

Calcule le numero de TVA intracommunautaire francais (FR + cle + SIREN) depuis un SIREN ou un SIRET, et controle la cle de Luhn. Calcul hors ligne.

eu_vat_validate

Valide un numero de TVA aupres du service VIES de la Commission europeenne et retourne la raison sociale et l'adresse declarees.

fr_bodacc_search

Recherche les annonces BODACC par SIREN ou denomination : creations, modifications, ventes, radiations, procedures collectives.

fr_compliance_check

Controle KYC complet : etat SIRENE, TVA/VIES, procedures collectives, anciennete, signaux de risque, score 0-100 et niveau.

Chaque outil accepte response_format : markdown (lecture humaine) ou json (traitement programmatique).

Related MCP server: eu-company-mcp-server

Sources de donnees

  • VIES - Commission europeenne, verification des numeros de TVA intracommunautaire.

  • BODACC - Bulletin officiel des annonces civiles et commerciales, DILA, via Opendatasoft.

  • API Recherche d'entreprises - base SIRENE diffusible, Etalab / data.gouv.fr.

Installation locale

npm install
npm run build
node dist/index.js

Connect via MCPize

Utilisez ce serveur MCP instantanément sans installation locale:

npx -y mcpize connect @contact.agentia1984/fr-compliance --client claude

Ou connectez-vous sur: https://mcpize.com/mcp/fr-compliance

Configuration Claude Desktop

{
  "mcpServers": {
    "fr-compliance": {
      "command": "node",
      "args": ["/chemin/vers/fr-compliance-mcp/dist/index.js"]
    }
  }
}

Deploiement heberge (HTTP Streamable)

TRANSPORT=http node dist/index.js

Le serveur ecoute sur 0.0.0.0 et lit process.env.PORT (8082 par defaut). Les endpoints MCP sont POST /mcp et POST /, plus GET /health.

Variables d'environnement

Variable

Valeur

Role

TRANSPORT

stdio (defaut) ou http

Choix du transport MCP.

PORT

entier

Port d'ecoute en mode HTTP.

Avertissement

Les resultats proviennent de sources publiques et sont fournis a titre informatif. Ils ne constituent ni un avis juridique, ni une decision de credit, ni un conseil financier.

Attribution et licence

Donnees BODACC : DILA, Licence Ouverte. Donnees entreprises : Etalab, Licence Ouverte 2.0. Code sous licence MIT.

Available Tools

4 tools
eu_vat_validateValider un numero de TVA intracommunautaire (VIES)A

Verifie en temps reel la validite d'un numero de TVA intracommunautaire aupres du service VIES de la Commission europeenne, et retourne la raison sociale et l'adresse declarees quand l'Etat membre les publie. Couvre les 27 Etats membres plus XI (Irlande du Nord).

ParametersJSON Schema
NameRequiredDescriptionDefault
vat_numberYesNumero de TVA avec son prefixe pays, ex: FR40303265045, BE0477472701, DE811569869.
response_formatNoFormat de sortie. 'markdown' pour lecture humaine, 'json' pour traitement programmatique.markdown

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses real-time validation, return of company name and address if published, and coverage. It does not mention rate limits, authentication, or side effects, but the core behavior is transparent enough.

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

Conciseness5/5

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

Two sentences, front-loaded with action verb 'Verifie'. No redundant words; every sentence adds value.

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?

Given the tool's simplicity (2 parameters, no output schema), the description sufficiently covers purpose, data source, coverage, and output format. No gaps.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for both parameters. The tool description adds no extra meaning beyond the schema, thus meets the baseline expectation.

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?

The description clearly states the tool validates a VAT number in real-time via the VIES service, returning company name and address. It specifies coverage of 27 EU states plus Northern Ireland, distinguishing it from siblings like fr_vat_compute which likely computes French VAT.

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?

The description indicates when to use (to validate an EU VAT number) and implies it is for real-time verification. However, it does not explicitly state when not to use or mention alternatives, though the sibling tools provide context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fr_compliance_checkControler la conformite et le risque d'une entreprise francaiseA

Realise un controle KYC complet a partir d'un SIREN : etat administratif SIRENE, calcul et validation VIES du numero de TVA intracommunautaire, procedures collectives publiees au BODACC et anciennete. Retourne des signaux de risque explicites, un score de 0 a 100 et un niveau faible, moyen ou eleve.

ParametersJSON Schema
NameRequiredDescriptionDefault
sirenYesSIREN (9 chiffres) ou SIRET (14 chiffres) de l'entreprise a controler.
response_formatNoFormat de sortie. 'markdown' pour lecture humaine, 'json' pour traitement programmatique.markdown

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the burden. It names data sources (SIRENE, VIES, BODACC) and outputs, but does not disclose behavioral traits such as external API calls, rate limits, permissions, or potential side effects. It is read-only in nature but this is not confirmed.

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?

A single sentence that covers the main functionality and outputs. It is front-loaded with the main purpose. Slightly more structure (e.g., bullet points) could improve readability but it is concise and effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain return value. It mentions risk signals, a score (0-100), and level (faible/moyen/eleve), which is adequate. However, it does not specify the format or structure of the risk signals, leaving some ambiguity for an agent.

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 100%, with both parameters having descriptions. The tool description adds context that the SIREN can be 9 or 14 digits and explains the response_format options, reinforcing but not significantly extending the schema.

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?

The description clearly states the tool performs a comprehensive KYC check from a SIREN, listing specific checks (administrative status, VIES validation, BODACC procedures, seniority) and outputs risk signals, score, and level. It is distinct from sibling tools which focus on individual components.

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

Usage Guidelines3/5

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

The description implies use for KYC compliance but does not explicitly differentiate from siblings like fr_vat_compute or fr_bodacc_search. No guidance on when to use this combined tool vs. individual tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fr_vat_computeCalculer le numero de TVA intracommunautaire francaisA

Calcule le numero de TVA intracommunautaire francais (FR + cle a 2 chiffres + SIREN) a partir d'un SIREN ou d'un SIRET, et controle la cle de Luhn. Calcul local instantane, aucun appel reseau. A utiliser avant eu_vat_validate quand on ne connait que le SIREN.

ParametersJSON Schema
NameRequiredDescriptionDefault
sirenYesSIREN (9 chiffres) ou SIRET (14 chiffres). Espaces et points acceptes.
response_formatNoFormat de sortie. 'markdown' pour lecture humaine, 'json' pour traitement programmatique.markdown

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It effectively discloses that the computation is local and instantaneous with no network dependency. However, it does not mention error handling or validation behavior for invalid inputs.

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

Conciseness5/5

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

The description is concise: two sentences that cover the core functionality and usage context. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple computation tool. It covers purpose, usage, and behavioral traits. It could benefit from mentioning error handling or the expected return value, but overall it provides sufficient context given the lack of output schema.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond what the schema already provides for the two parameters (siren and response_format). The schema already includes descriptions and defaults.

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?

The description clearly states the tool computes the French intra-community VAT number from a SIREN/SIRET, validating the Luhn key. It specifies the output format (FR + 2-digit key + SIREN) and distinguishes from sibling tool eu_vat_validate by stating it should be used before when only the SIREN is known.

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?

The description explicitly says when to use: before eu_vat_validate when only the SIREN is known. It also notes it's a local instant computation with no network call, providing clear context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • First observedeu_vat_validate
    • First observedfr_bodacc_search
    • First observedfr_compliance_check
    • First observedfr_vat_compute
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: local VAT calculation, EU VAT validation, BODACC search, and comprehensive KYC check. No ambiguity.

Naming Consistency5/5

All tools follow a consistent pattern of prefix (fr_ or eu_) + noun + verb (vat_compute, vat_validate, bodacc_search, compliance_check).

Tool Count5/5

4 tools is a well-scoped set for French compliance, covering key operations without being too few or too many.

Completeness5/5

The set covers essential compliance functions: VAT computation and validation, legal announcements search, and a full KYC check. No obvious gaps for the domain.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Data Gouv MCP Server

    csonigo
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables interaction with Datagouv APIs, primarily allowing users to search for up-to-date information about companies registered in France.
    11
    -

  • eu-company-mcp-server

    AiAgentKarl
    A
    license
    A
    quality
    D
    maintenance
    MCP server for EU company and business data. 9 tools: company search (GLEIF, 2M+ entities), LEI lookup, corporate structures (parent/subsidiaries), trade register search, EU VAT validation (VIES), GDP, unemployment, inflation, and business demography (Eurostat). All APIs free, no keys required.
    9
    4
    MIT

  • mcp-insee-entreprises

    DavidScanu
    F
    license
    Not graded
    quality
    D
    maintenance
    MCP server to query the INSEE SIRENE API and search for French companies, supporting searches by SIREN, SIRET, and advanced filters like name, location, and activity.
    1
    -

  • euinvoice-mcp

    artisan-at-work
    A
    license
    Not graded
    quality
    F
    maintenance
    An MCP server for European invoicing rules. Query VAT rates, e-invoicing requirements, format specifications, and compliance rules for EU-27 + EEA countries.
    24
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AgentIA1984-cmd/fr-compliance-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server