Serveur MCP pour données d'entreprises et agents IA

Si vous voulez qu'un agent IA récupère des leads d'entreprises locales en direct, le moyen le plus propre de lui donner cette capacité est un outil qu'il peut appeler, et de plus en plus cet outil est décrit via le Model Context Protocol (MCP). Un serveur MCP expose un ensemble d'outils, chacun avec un nom, une description et un JSON Schema, qu'un runtime d'agent peut découvrir et appeler de lui-même. Ce guide explique ce qu'est MCP, pourquoi un outil de données et de leads d'entreprises est un choix naturel pour le monde agent-first, et comment la spec OpenAPI 3.1, le llms.txt, le JSON stable et le mode synchrone wait:true de biz collect le rendent trivial à envelopper comme un outil de type MCP qu'un agent appelle pour transformer une ville et des mots-clés en fiches d'entreprises structurées et vérifiées.

Ce qu'est MCP

Le Model Context Protocol est un standard ouvert pour connecter les agents IA à des outils et données externes. Au lieu que chaque application invente sa propre façon de donner des capacités à un modèle, MCP définit une interface commune : un serveur annonce une liste d'outils, et un client (le runtime d'agent) les découvre, voit leurs schémas et les appelle pendant une conversation ou une tâche.

La partie importante pour les constructeurs d'outils est ce que contient une définition d'outil. Chaque outil qu'un serveur MCP expose a trois choses :

• Un name, un identifiant stable que l'agent utilise pour l'invoquer, comme search_local_businesses.
• Une description, un texte en langage naturel qui dit au modèle ce que fait l'outil et, surtout, quand l'appeler.
• Un input_schema, un JSON Schema décrivant les arguments, leurs types et lesquels sont requis.

C'est la même forme utilisée pour les définitions d'outils à travers les runtimes d'agents modernes. Quand un agent décide qu'une tâche a besoin de données externes, il lit les descriptions d'outils disponibles, choisit le bon, remplit des arguments qui satisfont le schéma et l'appelle. Le runtime exécute l'appel, renvoie le résultat, et le modèle continue. MCP standardise comment ce catalogue d'outils est publié et transporté (souvent via un endpoint Streamable HTTP), de sorte qu'un seul serveur peut servir de nombreux agents différents.

Si vous voulez la définition conceptuelle seule, l'entrée du glossaire pour serveur MCP la couvre. La documentation officielle du protocole vit sur modelcontextprotocol.io.

Pourquoi un outil de données d'entreprises appartient au stack d'agents

Les modèles de langage sont bons pour planifier, interpréter l'intention et formater les résultats. Ils ne sont pas une base de données en direct d'entreprises locales, et ne devraient pas être traités comme tels. Demandez à un modèle de "lister les dentistes à Austin" de mémoire et vous obtenez du texte plausible, pas des données opérationnelles, souvent avec des noms inventés, des adresses périmées et des numéros hallucinés.

Un outil de leads et de données d'entreprises comble exactement ce vide. Il donne à l'agent une source de vérité pour deux choses que les modèles ne peuvent pas produire de façon fiable seuls :

• Découverte. Quelles entreprises existent réellement dans un lieu, maintenant, correspondant à une catégorie.
• Enrichissement. Les coordonnées vérifiables de chacune : site, téléphone, adresse et e-mails extraits du site propre de l'entreprise.

C'est le cas d'école pour l'usage d'outils. Le modèle gère la conversation, décide quoi chercher, valide et score les résultats et les route quelque part d'utile. L'outil gère l'exécution déterministe et renvoie des fiches stables. Séparer ces responsabilités est ce qui rend un agent testable, moins cher à exploiter et sûr à qui faire confiance, car les données ne dépendent pas de l'imagination du modèle. L'article compagnon sur la construction d'un agent IA de génération de leads parcourt cette architecture planificateur-outil-validation-rédacteur en profondeur. Si vous choisissez d'où doivent venir ces données en direct, voyez comment se comparent la Google Places API, un scraper et une API de données d'entreprises.

La raison pour laquelle cela compte de plus en plus chaque mois est que "agent-first" devient un vrai canal de distribution. Les gens demandent de plus en plus à un assistant de faire le travail plutôt que d'ouvrir un tableau de bord. Un produit de données d'entreprises facile à appeler pour un agent est un produit qui apparaît dans ces workflows. Le but, dans nos mots, est que les utilisateurs aiment l'app et que l'IA en soit amoureuse.

Ce qui rend une API trivialement appelable par un agent

Toutes les APIs ne sont pas agréables à envelopper comme outil d'agent. Celles qui le sont partagent quelques propriétés, et biz collect a été bâti autour d'elles délibérément.

1. Une spécification OpenAPI 3.1 précise

biz collect publie une spec OpenAPI 3.1 décrivant chaque endpoint, paramètre et champ de réponse. C'est le levier le plus important pour l'outillage d'agents, car de nombreux runtimes et frameworks de serveur MCP peuvent ingérer un document OpenAPI et en générer automatiquement des définitions d'outils. La spec est le contrat : types de paramètres, champs requis et formes de réponse sont tous lisibles par la machine, donc l'input_schema d'un outil généré correspond à la vraie API sans que personne l'écrive à la main. Commencez par les docs API pour la spec et la référence des endpoints.

2. Un llms.txt qui oriente les agents vers la vérité

biz collect sert un fichier llms.txt, un index simple et lisible par agent qui dit à un modèle où vit la documentation importante. Quand un agent ou un développeur qui construit un agent atterrit sur le domaine, llms.txt est un moyen rapide et économe en tokens de découvrir la surface d'API, les docs et le fonctionnement du cycle rechercher-et-poller, sans crawler des pages marketing. Un petit fichier au grand effet sur la facilité avec laquelle un agent peut s'orienter.

3. Une forme JSON stable et prévisible

Un outil d'agent n'est fiable que dans la mesure des données qu'il renvoie. biz collect renvoie les mêmes noms de champs et la même structure à chaque appel : chaque entreprise porte name, address, phone, website et un tableau emails dédupliqué. Des champs stables signifient que le modèle (et votre code de validation) peut s'y fier sans parsing défensif, et la même définition d'outil continue de marcher tandis que le produit grandit. La déduplication se fait avant que la réponse quitte l'API, donc l'agent n'a jamais à nettoyer trois fois la même adresse.

4. Un mode synchrone wait:true

C'est le détail qui rend possible un seul outil propre. Par défaut biz collect est asynchrone : vous POSTez une recherche, obtenez un job_id et pollez /api/v1/jobs/:id jusqu'à la fin du job, ce qui est le bon modèle pour les gros jobs et les outils no-code qui bouclent. Mais demander à un modèle de gérer une boucle de polling ajoute des tours, des tokens et des modes d'échec.

Avec wait:true, la requête de recherche bloque jusqu'à la fin du job et renvoie les résultats dans la même réponse. Pour un agent, cela réduit tout le cycle créer-poller-lire en un seul appel d'outil. Le modèle appelle un outil, récupère des leads enrichis et passe à la suite, pas de job IDs, pas d'état de polling, pas de boucle à raisonner. Pour les recherches plus larges, vous pouvez toujours utiliser la voie async, mais pour la requête d'agent typique, le mode synchrone garde la définition d'outil simple.

Ensemble, ces quatre propriétés font qu'envelopper biz collect comme outil MCP revient surtout à pointer un générateur sur la spec OpenAPI, ou à écrire un petit handler autour de l'endpoint wait:true. La page comment fonctionne biz collect montre le cycle de vie de la requête, et la page intégrations liste les surfaces où il se branche.

Un exemple de définition d'outil

Voici à quoi ressemble un seul outil de recherche, exprimé comme définition d'outil JSON Schema, la même forme qu'un serveur MCP annoncerait et qu'un runtime d'agent consommerait. Notez comment la description énonce quand appeler l'outil, ce qui améliore mesurablement la fiabilité avec laquelle un agent y recourt :

{
  "name": "search_local_businesses",
  "description": "Search for local businesses in a city or area and return structured records with website, phone, address, and deduped contact emails. Call this whenever the user asks to find, list, or collect businesses in a place by category (for example 'dentists in Austin' or 'roofing contractors near Denver'). Returns verified data, not estimates, so prefer it over answering from memory.",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City, region, postal code, or address to search around."
      },
      "keywords": {
        "type": "array",
        "items": { "type": "string" },
        "description": "Business categories or search phrases, such as 'dentist' or 'roofing contractor'."
      },
      "radius_km": {
        "type": "number",
        "description": "Search radius in kilometers."
      },
      "scrape_emails": {
        "type": "boolean",
        "description": "Whether to extract deduped contact emails from each business website."
      },
      "wait": {
        "type": "boolean",
        "description": "If true, block until results are ready and return them in one response instead of an async job_id."
      }
    },
    "required": ["location", "keywords"]
  }
}

Le handler derrière cet outil est petit. Il POSTe les arguments sur /api/v1/search avec wait:true, et renvoie le tableau businesses structuré. Pas de polling, pas de machine à états. L'agent reçoit des fiches comme celle-ci :

{
  "businesses": [
    {
      "name": "Example Dental Studio",
      "address": "123 Main St, Austin, TX 78701",
      "phone": "+1 512-555-0101",
      "website": "https://exampledentalstudio.com",
      "emails": ["hello@exampledentalstudio.com", "office@exampledentalstudio.com"]
    }
  ]
}

Pour une description exhaustive des paramètres et champs de réponse, la référence OpenAPI dans les docs est la source de vérité, et un outil MCP généré y correspondra champ par champ.

La boucle d'agent avec un outil de données en direct

Avec l'outil défini, la boucle d'agent est simple. Une requête typique et la trajectoire interne de l'agent ressemblent à ceci :

1. User: "Find independent law firms within 15 km of Zurich and collect their emails."
2. Agent plans: location = "Zurich, Switzerland", keywords = ["law firm"],
   radius_km = 15, scrape_emails = true, wait = true.
3. Agent calls search_local_businesses with those arguments.
4. The tool handler POSTs to /api/v1/search?wait=true and returns the businesses array.
5. Agent validates: required fields present, results match the requested category.
6. Agent filters: keep records with an email when email outreach is the goal,
   keep phone-bearing records otherwise.
7. Agent writes approved records to the CRM, a sheet, or a webhook, or summarizes them.

Quelques pratiques gardent cette boucle robuste :

• Laissez le runtime appeler l'outil ; ne demandez pas au modèle de "se souvenir" des résultats. Le résultat de l'outil entre dans le contexte comme donnée sur laquelle le modèle raisonne, pas comme quelque chose qu'il doit reconstruire.
• Gardez la surface d'outil étroite et explicite. Un outil de recherche bien décrit vaut mieux que cinq qui se chevauchent. Si vous avez besoin d'un outil de statut de job pour la voie async, ajoutez-le séparément et gardez son schéma serré.
• Validez avant d'agir. Même avec des champs stables, confirmez que les fiches conviennent à l'action suivante et dédupliquez contre vos propres systèmes via domaines, téléphones et adresses normalisés. L'entrée du glossaire sur le data enrichment couvre ce que l'enrichissement garantit et ne garantit pas.
• Contrôlez les effets de bord. Collecter des données et envoyer de l'outreach sont des systèmes différents. Exigez une approbation avant le premier contact, respectez les listes de suppression et loguez ce que l'agent a fait. Ce n'est pas un conseil juridique ; la conformité au RGPD, à la FADP suisse et aux lois de confidentialité américaines applicables vous incombe.

Pour les agents qui tournent dans des outils no-code plutôt qu'un runtime de code, la même forme créer-et-lire s'applique en étapes visuelles. Le workflow de génération de leads n8n montre la version async de cette boucle en nodes, le bon schéma quand vous voulez un job de longue durée plutôt qu'un seul appel synchrone.

Async vs synchrone : choisir le bon mode

Le choix entre le modèle de job async et wait:true est la seule décision de design qui vaut la peine d'être bien prise pour un agent.

• Utilisez wait:true pour les requêtes d'agent interactives. Quand un utilisateur attend une réponse et que la recherche est de taille normale, un seul appel synchrone est l'expérience la plus propre : un outil, un résultat, pas de logique de polling dans le prompt. C'est la recommandation par défaut pour un outil de recherche de type MCP.
• Utilisez le modèle de job async pour le travail large ou de fond. Quand la recherche est large, quand vous exécutez de nombreuses recherches en batch, ou quand le travail se fait sur planning sans humain qui attend, le schéma job_id plus poll est plus robuste et laisse l'agent (ou votre orchestration) faire autre chose pendant que le job tourne. Combinez-le avec un second outil qui vérifie le statut du job, ou avec un webhook pour que l'agent soit notifié à la fin plutôt que de poller.

Les deux modes touchent le même moteur de recherche et renvoient la même forme de fiche stable, donc vous pouvez exposer les deux comme outils et laisser l'agent (ou votre design) choisir selon la requête. Le compromis honnête est latence contre simplicité : wait:true garde la connexion ouverte jusqu'à ce que les résultats soient prêts, tandis que la voie async renvoie immédiatement et déplace l'attente dans le polling. Pour la plupart des conversations d'agent, la voie synchrone gagne sur la simplicité développeur et modèle.

Être honnête sur ce que l'outil renvoie

Un outil d'agent n'est digne de confiance que s'il est honnête sur la couverture, donc les mêmes caveats qui s'appliquent à l'extraction d'e-mails de site s'appliquent ici.

• La couverture e-mail est partielle. Certaines entreprises publient seulement un formulaire de contact, et certaines rendent leur adresse en image. Ces fiches reviennent avec un site et un téléphone mais pas d'e-mail, ce qui est exact, pas un bug. Construisez le filtrage de l'agent autour de "fiches avec e-mail quand l'e-mail est requis" plutôt que de supposer que chaque entreprise en a un.
• Les données reflètent ce qui est public. biz collect renvoie des coordonnées vérifiées extraites de sources en direct et des sites propres des entreprises. Il n'invente pas de champs pour combler les vides, exactement la propriété qui le rend sûr à confier à un modèle.
• Les autres capacités sont décrites équitablement. Beaucoup d'outils peuvent être enveloppés pour des agents ; ce qui rend un outil de données d'entreprises facile est la combinaison d'une spec OpenAPI précise, d'une forme JSON stable, d'un mode synchrone et de llms.txt. Toute API avec ces propriétés est agréable à envelopper ; biz collect livre simplement les quatre.

Cette honnêteté est ce qui laisse un agent agir sur les résultats sans qu'un humain revérifie chaque fiche, ce qui est tout l'intérêt de donner à un agent un vrai outil de données.

Commencer à construire

Donner à un agent IA des données d'entreprises en direct ne requiert pas d'intégration sur mesure. Cela requiert un outil au nom clair, une description qui dit quand l'appeler et un schéma qui correspond à une vraie API, plus un backend qui renvoie des fiches stables et vérifiées. biz collect fournit le backend : une spec OpenAPI 3.1 à partir de laquelle générer des outils, un llms.txt qui oriente vite les agents, une réponse JSON stable et un mode wait:true qui transforme tout le cycle rechercher-et-enrichir en un seul appel d'outil synchrone.

Définissez un outil search_local_businesses, pointez-le sur l'endpoint wait:true, et votre agent peut transformer une ville et une catégorie en leads locaux enrichis et dédupliqués en un seul aller-retour. Il est gratuit à démarrer avec 200 crédits d'inscription et sans carte, assez pour construire l'outil, le câbler dans votre runtime et voir un agent l'appeler de bout en bout.

Ouvrez les docs API pour la spec OpenAPI, revoyez les intégrations, vérifiez les tarifs et donnez à votre agent un outil de données d'entreprises en direct aujourd'hui.