Serveur MCP

Introduction

Le Model Context Protocol est un standard ouvert qui décrit comment un agent d’IA accède à des outils et à des données externes. Au lieu de programmer une interface, vous ajoutez le serveur une seule fois à la configuration de l’agent. Le modèle sait dès lors quels outils existent et les appelle lui-même quand la conversation l’exige.

Notre serveur expose les mêmes données que l’API REST : annonces, profils d’entreprises, chiffres financiers, mandataires et administrateurs, statistiques et liste de surveillance. La différence tient à la présentation. Les descriptions des outils sont rédigées pour qu’un modèle comprenne quand une vérification de défaillance a du sens, quels détails il doit demander et où se situent les limites des données.

L’adresse est https://failliteradar.fr/api/mcp. Elle utilise les mêmes clés que l’API REST. Si vous exploitez les deux en parallèle, vous verrez la même liste de surveillance des deux côtés.

Accès

La démarche est la même que pour l’API REST : les clés sont attribuées manuellement. Utilisez le formulaire de contact ou écrivez à [email protected] en indiquant brièvement quel agent vous souhaitez connecter et ce qu’il doit faire.

Si vous avez déjà une clé d’API, vous n’en avez pas besoin d’une seconde : la même clé ouvre le serveur MCP. Les équipes qui veulent donner accès au serveur à plusieurs personnes peuvent recevoir plusieurs clés sur un même compte, afin de garder la traçabilité de qui a vérifié quoi.

Connexion et transport

Le serveur parle MCP via Streamable HTTP, le transport que les clients actuels utilisent par défaut. Aucun processus local n’est nécessaire, il n’y a rien à installer.

L’authentification utilise le même en-tête que l’API REST : X-API-Key, ou bien Authorization: Bearer. Comme la clé d’API elle-même, le serveur est lié à son marché : le serveur sur failliteradar.fr répond au sujet des entreprises en France. Les clients qui ne parlent que stdio y accèdent via mcp-remote comme passerelle, voir la configuration de Claude Desktop ci-dessous.

Le client et le serveur négocient la version du protocole à la connexion. Nous prenons en charge la révision actuelle et la précédente, de sorte qu’une mise à jour du client ne provoque jamais de rupture brutale.

curl https://failliteradar.fr/api/mcp/health

Configuration

Dans Claude Code, une seule commande suffit. La clé doit provenir d’une variable d’environnement, pas du presse-papiers.

claude mcp add --transport http failliteradar \
  https://failliteradar.fr/api/mcp \
  --header "X-API-Key: $FAILLITE_API_KEY"

Claude Desktop

Claude Desktop lit sa liste de serveurs dans claude_desktop_config.json. L’entrée fait le pont vers le transport HTTP via mcp-remote.

{
  "mcpServers": {
    "failliteradar": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://failliteradar.fr/api/mcp",
        "--header", "X-API-Key:${FAILLITE_API_KEY}"
      ],
      "env": { "FAILLITE_API_KEY": "YOUR_API_KEY" }
    }
  }
}

Cursor et autres clients

Cursor, Windsurf, Zed et la plupart des autres clients prennent directement l’URL du serveur et autorisent leurs propres en-têtes, aucune passerelle n’est donc nécessaire.

{
  "mcpServers": {
    "failliteradar": {
      "url": "https://failliteradar.fr/api/mcp",
      "headers": { "X-API-Key": "${env:FAILLITE_API_KEY}" }
    }
  }
}

Une fois ajouté, le client doit afficher onze outils. Si la liste reste vide, c’est presque toujours l’en-tête : une clé expirée ou mal saisie produit une liste d’outils vide plutôt qu’une erreur visible.

Outils

Le serveur fournit onze outils. Les outils d’écriture sont signalés comme tels, afin que les clients puissent demander une confirmation là où ils le souhaitent.

Tous les outils de lecture sont idempotents et peuvent être appelés sans demander. watch_company et unwatch_company modifient votre compte et se signalent au client comme des outils d’écriture.

check_counterparty en détail

L’outil qui compte est check_counterparty. Son schéma est volontairement étroit : un nom ou un numéro d’entreprise, en option la ville et une date de début. Moins un modèle a de décisions à prendre, moins souvent il invente des valeurs.

{
  "name": "check_counterparty",
  "description": "Check whether a company in France appears in official insolvency filings. Use before extending credit, signing a supplier or chasing an overdue invoice. Prefer the company number over the name when you have it. Never guess a company number.",
  "annotations": { "readOnlyHint": true },
  "inputSchema": {
    "type": "object",
    "properties": {
      "name":           { "type": "string", "description": "Company name as written on the invoice or contract." },
      "city":           { "type": "string", "description": "Registered town, narrows ambiguous names." },
      "company_number": { "type": "string", "description": "National register number, e.g. 912345678" },
      "since":          { "type": "string", "format": "date", "description": "Only filings on or after this date. Default: 3 years ago." }
    },
    "anyOf": [ { "required": ["name"] }, { "required": ["company_number"] } ]
  }
}

La description demande explicitement au modèle de privilégier le numéro d’entreprise et de ne jamais en deviner un. Un numéro erroné mène à un « aucune annonce » assuré pour la mauvaise entreprise, ce qui est pire qu’une réponse ambiguë.

Si un nom n’est pas unique, l’outil n’en choisit pas un mais renvoie un texte d’erreur indiquant le nombre de candidats. Le modèle demande alors à l’utilisateur la ville ou le numéro d’entreprise. Ce comportement est voulu et est traité dans la section gestion des erreurs.

Sans since, l’outil remonte trois ans en arrière. Les procédures plus anciennes sont en général closes et n’ont plus d’importance pour les décisions actuelles ; si elles en ont, transmettez une date plus ancienne.

Format des réponses

Les outils répondent sur deux voies : un bloc de texte pour le modèle et structuredContent pour le client. Le bloc de texte est rédigé de manière à ce que le modèle puisse le restituer sans l’interpréter au préalable : entreprise, numéro d’entreprise, type de procédure, date, tribunal ou registre, référence et source.

{
  "content": [
    {
      "type": "text",
      "text": "EXEMPLE BÂTIMENT SAS (912345678, Lyon): Liquidation judiciaire filed on 2026-09-28. Issued by Tribunal de commerce de Lyon, reference A202601870452. Source: BODACC."
    },
    {
      "type": "resource_link",
      "uri": "faillite://company/912345678/filings",
      "name": "Filings of EXEMPLE BÂTIMENT SAS",
      "mimeType": "application/json"
    }
  ],
  "structuredContent": {
    "match": "exact",
    "company_number": "912345678",
    "status": "liquidation",
    "filings": [
      { "date": "2026-09-28", "type_code": "liquidation-judiciaire", "case_number": "A202601870452" }
    ]
  },
  "isError": false
}

Les contenus volumineux, comme l’historique complet des annonces, reviennent sous forme de lien de ressource et non intégrés. Un client qui veut l’afficher résout le lien ; un client qui ne le veut pas garde sa fenêtre de contexte petite.

Ressources

En plus des outils, le serveur fournit des ressources sous le schéma faillite://. Les clients qui prennent en charge les ressources peuvent les afficher ou les joindre au modèle sans appeler d’outil.

faillite://company/{number}              company profile and status
faillite://company/{number}/filings      all filings of a company
faillite://company/{number}/financials   published accounts figures
faillite://practitioner/{id}             appointed practitioner or office
faillite://watchlist                     your watched companies
faillite://types                         filing types with keys and aliases

La ressource de liste de surveillance change lorsqu’une nouvelle annonce concerne une entreprise surveillée. Le serveur envoie alors une notification de changement, afin que les clients puissent actualiser leur affichage.

Prompts

Pour les tâches récurrentes, des prompts prêts à l’emploi existent. Ils rassemblent ce dont la tâche a besoin, puis appellent les outils appropriés. Dans les clients qui prennent en charge les prompts, ils apparaissent comme des commandes rapides.

{
  "name": "counterparty_check",
  "description": "Check a list of customers or suppliers for insolvency filings and summarise the risk.",
  "arguments": [
    { "name": "companies", "description": "One company per line: name, town or company number.", "required": true },
    { "name": "since",     "description": "Look-back start date, default 3 years.", "required": false }
  ]
}

Sont actuellement disponibles counterparty_check (vérifier une liste d’entreprises), weekly_briefing (nouvelles annonces de la semaine pour des régions ou secteurs choisis) et company_timeline (historique de la procédure collective d’une entreprise, expliqué en langage clair). Si vous préférez votre propre enchaînement, ignorez les prompts et appelez directement les outils.

Exemple de conversation

Voici à quoi cela ressemble en pratique. L’agent vérifie trois clients, explique les résultats en termes simples, pose une question de précision lorsque le nom est ambigu, puis met en place la surveillance.

Utilisateur :   Vérifie ces trois clients avant que nous renouvelions leurs
                lignes de crédit : EXEMPLE BÂTIMENT SAS, TRANSPORTS DUPONT-EXEMPLE SARL, BOULANGERIE DU PORT SARL.

Agent :  [check_counterparty name="EXEMPLE BÂTIMENT SAS"]
         [check_counterparty name="TRANSPORTS DUPONT-EXEMPLE SARL"]
         [check_counterparty name="BOULANGERIE DU PORT SARL"]

Agent :  EXEMPLE BÂTIMENT SAS (912345678, Lyon) : Liquidation judiciaire
         enregistré le 2026-09-28, référence A202601870452, Tribunal de commerce de Lyon.
         Je ne renouvellerais pas la ligne de crédit.

         TRANSPORTS DUPONT-EXEMPLE SARL : aucune procédure collective sur les trois
         dernières années.

         BOULANGERIE DU PORT SARL : deux entreprises portent ce nom. Dans quelle
         ville se trouve votre client ?

Utilisateur :   Marseille.

Agent :  [check_counterparty name="BOULANGERIE DU PORT SARL" city="Marseille"]
         Aucune procédure pour l’entreprise de Marseille.
         Dois-je placer les trois sous surveillance, afin que vous
         soyez informé immédiatement de toute nouvelle annonce ?

Utilisateur :   Oui.

Agent :  [watch_company company_number="912345678" ref="EXEMPLE BÂTIMENT SAS"]
         [watch_company name="TRANSPORTS DUPONT-EXEMPLE SARL"]
         [watch_company name="BOULANGERIE DU PORT SARL" city="Marseille"]
         C’est fait. Les trois sont sous surveillance.

L’étape importante est la troisième : face à un nom ambigu, l’agent demande au lieu de choisir. C’est précisément à cela que sert le texte d’erreur de l’outil.

Autorisations

Chaque clé porte des autorisations. Par défaut, elle peut lire les annonces, entreprises, mandataires et statistiques ; l’écriture dans la liste de surveillance doit être activée séparément.

Les outils pour lesquels la clé n’a aucune autorisation n’apparaissent pas du tout dans la liste des outils. C’est plus agréable qu’une erreur en pleine conversation, car le modèle ne propose alors jamais quelque chose qu’il ne peut pas faire.

Gestion des erreurs

Les erreurs reviennent comme un résultat d’outil normal avec isError: true, et non comme une erreur de protocole. Le texte s’adresse au modèle et lui indique ce qu’il doit faire ensuite, de sorte que l’agent peut réagir de façon sensée au cours de la conversation.

{
  "content": [
    {
      "type": "text",
      "text": "No unique match: 2 companies are called \"BOULANGERIE DU PORT SARL\". Ask the user for the town or the company number and call check_counterparty again. Do not pick one yourself."
    }
  ],
  "isError": true
}

De véritables erreurs de protocole n’apparaissent qu’avec une clé invalide, une autorisation manquante ou une requête mal formée. Tout ce qui peut mal tourner sur le fond, comme un nom ambigu, un numéro d’entreprise inconnu, un type de procédure inconnu ou une période de plus de 31 jours, revient sous forme de texte.

Limites

Les mêmes limites s’appliquent que pour l’API REST : 120 appels d’outil par minute et par clé, au maximum 31 jours et 10 000 lignes par recherche d’annonces, 24 mois pour les statistiques. Pour des valeurs plus élevées, un e-mail suffit.

Le dépassement d’une limite ne produit pas d’erreur brutale mais un résultat textuel indiquant quand la reprise est possible. Les agents devraient alors attendre plutôt que réappeler immédiatement.

Données et responsabilité

Le serveur renvoie des annonces publiques du BODACC, qui peuvent contenir des données personnelles. Les mêmes règles s’appliquent que pour l’API REST : RGPD, aucune publication concernant des personnes physiques en dehors de leur contexte professionnel, aucune décision automatisée concernant des personnes physiques fondée uniquement sur ces données.

Un agent peut résumer une annonce, mais cela ne remplace pas un conseil juridique. Les textes des outils nomment donc toujours le tribunal ou le registre ainsi que la référence, afin que l’utilisateur puisse vérifier l’original. Nous recommandons que votre agent le rappelle également lorsqu’il en déduit des recommandations d’action.

Ce que l’agent envoie au serveur (noms d’entreprises, vos références) sert uniquement à répondre à la requête et n’est pas transmis à des tiers. Si votre agent traite des données concernant vos clients, un contrat de sous-traitance des données personnelles est disponible.

Exploitation

Le serveur tourne sur la même infrastructure que l’API REST. Les fenêtres de maintenance sont annoncées par e-mail à l’adresse enregistrée, et les modifications des schémas d’outils sont uniquement additives.

Lorsqu’un nouvel outil est ajouté, le serveur envoie une notification de changement. Les clients qui y réagissent voient l’outil sans redémarrage. Les outils existants conservent leurs noms et leurs champs obligatoires.

Assistance

Questions, limites plus élevées, prompts ou outils sur mesure pour un flux de travail précis : [email protected] ou le formulaire de contact.

Si vous préférez travailler directement en HTTP, les mêmes données sont documentées sous forme d’interface REST dans la documentation de l’API. Les deux voies partagent clés, limites et contrat.