Créer des workflows d'agents IA avec le Web MCPAccès web en direct pour les agents

Si vous avez déjà connecté un agent IA au web en direct, vous savez déjà où ça coince. L'agent raisonne bien, mais dès qu'il a besoin du contenu réel d'une page, il se heurte à un mur : le site s'affiche côté client, le HTML est un fouillis, ou la requête est bloquée avant qu'aucune donnée ne revienne. La solution n'est pas un prompt plus intelligent. C'est donner à l'agent un outil qui retourne des données web propres et structurées à la demande, et laisser l'agent décider quand l'appeler.

C'est exactement ce que fournit le serveur Crawlbase Web MCP. Ce guide vous montre comment construire des workflows d'agents IA autour du Crawlbase Web MCP : la boucle de planification que l'agent exécute, les appels d'outils MCP qu'il effectue pour scraper et crawler, et un exemple concret de bout en bout qui prend une URL, récupère la page rendue et retourne une réponse structurée. Pas de code de scraping personnalisé, pas de pool de proxys à surveiller, pas de règles de parsing intégrées dans l'agent.

Ce que le Crawlbase Web MCP apporte à un agent

MCP, le Model Context Protocol, est le standard ouvert qui permet à un modèle de langage d'appeler des outils externes via une interface cohérente. Un serveur MCP publie un ensemble d'outils, et tout client compatible MCP (Claude Desktop, Cursor, n8n, ou votre propre agent) peut les découvrir et les invoquer. Le serveur Crawlbase MCP publie des outils d'accès web, de sorte que l'agent acquiert la capacité de lire n'importe quelle URL publique comme le ferait un vrai navigateur.

En coulisses, ces outils s'appuient sur la même Crawling API qui alimente le reste de Crawlbase. Cela signifie que l'agent hérite du rendu JavaScript, de la rotation d'IPs résidentielles, de la gestion des anti-bots, des tentatives de reprise, et d'une sortie propre, sans en avoir la moindre connaissance. Du point de vue de l'agent, il a simplement appelé un outil et obtenu du contenu lisible en retour. Pour une présentation complète de ce qu'expose le serveur, consultez notre introduction au Crawlbase MCP.

Le Web MCP expose généralement deux outils que votre agent utilisera :

• crawl récupère une URL unique et retourne la page rendue sous forme de markdown propre ou de HTML, prêt à être lu par le modèle.
• crawl_markdown (ou une variante screenshot/structurée, selon votre build de serveur) retourne le même contenu réduit à du texte lisible, ce qui maintient l'utilisation de tokens à un niveau bas pour les longues pages.

La boucle de l'agent, étape par étape

Un workflow d'agent est une boucle, pas une ligne droite. Le modèle planifie, choisit un outil, lit le résultat, et décide s'il a suffisamment pour répondre ou s'il a besoin d'un autre appel. Avec le Web MCP connecté, cette boucle ressemble à ceci :

• Recevoir la tâche. L'agent reçoit une instruction qui contient généralement une URL ou un sujet à rechercher.
• Planifier. Il détermine s'il peut répondre à partir de ce qu'il sait ou s'il a besoin de données web en direct.
• Appeler l'outil MCP. Quand il a besoin de la page, il invoque crawl avec l'URL cible.
• Lire le résultat. Crawlbase retourne du contenu propre et rendu, que le modèle ingère comme sortie d'outil.
• Décider. Assez pour répondre ? Il écrit la réponse structurée. Pas encore ? Il boucle, en crawlant une autre URL ou en affinant la requête.
• Retourner. Il remet un résultat propre et structuré dans la forme que vous avez demandée.

Le changement important est que la décision de scraper est prise par l'agent, pas codée en dur par vous. Vous décrivez l'objectif ; l'agent détermine quelles pages il a besoin et quand les récupérer.

Étape 1 : Lancer le serveur Crawlbase Web MCP

Tout client MCP se connecte au serveur via un petit bloc de configuration. Vous pointez le client vers le package MCP de Crawlbase et passez votre token via l'environnement. Voici une configuration typique pour un client MCP de bureau.

{
  "mcpServers": {
    "crawlbase": {
      "command": "npx",
      "args": ["-y", "@crawlbase/mcp"],
      "env": {
        "CRAWLBASE_TOKEN": "YOUR_CRAWLBASE_JS_TOKEN"
      }
    }
  }
}

Utilisez votre token JavaScript (JS) ici. Crawlbase émet deux types de tokens : le token normal récupère le HTML statique, tandis que le token JS rend la page dans un vrai navigateur d'abord. Puisque la plupart des sites qui valent la peine d'être crawlés sont rendus côté client, le token JS est la valeur par défaut sûre pour le travail d'agent. Vous obtenez les deux tokens depuis le tableau de bord après vous être inscrit.

Si vous utilisez une plateforme d'agent comme n8n plutôt qu'un client de bureau, vous vous connectez à un endpoint MCP hébergé via HTTP plutôt que de lancer le processus localement. La configuration complète de n8n est couverte dans la connexion de n8n avec le Crawlbase Web MCP ; le reste de ce guide construit l'agent en code afin que vous puissiez voir la boucle directement.

Étape 2 : Construire l'agent qui appelle les outils MCP

Connectez maintenant un vrai agent au serveur. Le pattern ci-dessous utilise Python avec une bibliothèque client MCP et un modèle à appel d'outils. L'agent se connecte au serveur Crawlbase MCP, découvre les outils disponibles, et les transmet au modèle pour qu'il décide quand crawler.

import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

server = StdioServerParameters(
    command="npx",
    args=["-y", "@crawlbase/mcp"],
    env={"CRAWLBASE_TOKEN": "YOUR_CRAWLBASE_JS_TOKEN"},
)

async def connect():
    async with stdio_client(server) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            tools = await session.list_tools()
            print([t.name for t in tools.tools])
            return session

asyncio.run(connect())

L'exécution de ce code affiche les noms des outils exposés par le serveur, confirmant que l'agent peut voir crawl et ses dérivés avant de demander au modèle de les utiliser. Cette étape de découverte est ce qui rend le workflow portable : remplacez par un autre serveur MCP plus tard et l'agent s'adapte à tous les outils qu'il trouve.

Étape 3 : Donner au modèle une boucle d'appel d'outils

Une fois la session active, la boucle est simple. Vous donnez au modèle la tâche et la liste des outils, le laissez émettre un appel d'outil, exécutez cet appel contre le serveur MCP, renvoyez le résultat, et répétez jusqu'à ce que le modèle arrête d'appeler des outils et écrive sa réponse.

async def run_agent(session, model, task):
    messages = [{"role": "user", "content": task}]
    tools = (await session.list_tools()).tools

    while True:
        reply = await model.chat(messages, tools=tools)

        if not reply.tool_calls:
            return reply.content

        for call in reply.tool_calls:
            result = await session.call_tool(call.name, call.arguments)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result.content,
            })

Cette boucle while constitue l'intégralité de l'agent. Le modèle planifie, appelle crawl quand il veut la page, lit le markdown que Crawlbase retourne, puis répond ou crawler à nouveau. Vous ne lui dites jamais quelle URL récupérer ni quand la récupérer ; vous décrivez le résultat et il s'y dirige lui-même.

Étape 4 : Orienter l'agent avec un prompt système

L'unique endroit où l'ambiguïté s'introduit est de savoir si le modèle est sûr qu'il devrait utiliser l'outil. Un message système court et explicite dissipe le doute et verrouille une forme de sortie cohérente.

SYSTEM = """You are a web research assistant with crawl tools.

Always use the crawl tool to read a URL before answering about it.
Never guess page contents from memory. After crawling, extract only
the fields requested and return them as structured JSON."""

task = (
    "Crawl https://www.example-store.com/product/123 and return "
    "the product name, price, rating, and a one-line summary."
)

Avec cela en place, une seule exécution produit un objet propre : l'agent crawle la page, lit le contenu rendu que Crawlbase retourne, et émet exactement les champs que vous avez demandés. C'est la même idée qui sous-tend l'extraction de données par IA, sauf que le modèle décide lui-même quand accéder à la page.

Un workflow concret : surveillance des prix concurrents

Assemblez les pièces en un workflow que vous exécuteriez réellement. Supposons que vous vouliez une vérification quotidienne sur quelques pages de produits concurrents : prix actuel, disponibilité, et toute bannière promotionnelle. Vous donnez la liste à l'agent et le laissez travailler.

urls = [
    "https://competitor-a.com/p/widget",
    "https://competitor-b.com/p/widget",
]

async def price_watch(session, model):
    rows = []
    for url in urls:
        task = f"Crawl {url}. Return price, in_stock, promo as JSON."
        rows.append(await run_agent(session, model, task))
    return rows

Chaque itération exécute la boucle complète de l'agent : le modèle crawle l'URL via l'outil MCP, Crawlbase la rend et fait tourner l'IP, et l'agent retourne une ligne structurée. La sortie est un tableau ordonné que vous pouvez comparer à l'exécution d'hier, envoyer vers une feuille de calcul, ou sur lequel déclencher une alerte quand un prix bouge.

Le même squelette s'adapte à d'autres tâches sans réécriture. Changez la chaîne de tâche et vous avez un moniteur d'actualités, un assistant de recherche qui rassemble des notes de plusieurs sources, ou une étape d'enrichissement de leads sur des pages d'entreprises publiques. Parce que l'agent parle à Crawlbase via un seul outil stable, le pointer sur un nouveau site ne nécessite aucun nouveau câblage API. Pour en savoir plus sur l'endroit où cela s'insère, le récapitulatif des cas d'usage de proxy IA parcourt des patterns adjacents.

Affiner les crawls pour les pages difficiles

La plupart des pages se crawlent proprement avec les valeurs par défaut, mais les applications à page unique lourdes ont parfois besoin d'une indication. Les outils MCP acceptent les mêmes options d'attente que la Crawling API, donc vous pouvez les passer dans les arguments d'outil quand une page s'affiche tardivement. Deux paramètres comptent le plus : un indicateur ajax-wait qui attend le contenu asynchrone, et une valeur page-wait en millisecondes pour une pause fixe après le chargement.

{
  "url": "https://www.example-store.com/product/123",
  "ajax_wait": true,
  "page_wait": 5000
}

Si les résultats reviennent incomplets, augmentez page_wait avant de chercher autre chose. Vous pouvez laisser l'agent définir ces paramètres lui-même en décrivant la page dans le prompt système ("pour les applications à page unique lentes, attendre le contenu ajax"), ou les coder en dur dans un wrapper quand vous savez que la cible est lourde. Dans tous les cas, le comportement de rendu, rotation et reprise reste côté Crawlbase ; l'agent lit simplement le résultat.

Si un site est si hostile que même les crawls rendus ont du mal, le Smart AI Proxy vous donne un endpoint rotatif unique pour acheminer les requêtes, et la Crawling API retourne du JSON pré-analysé pour les sites populaires quand vous préférez éviter que le modèle analyse la page lui-même. Les deux partagent la même infrastructure sur laquelle reposent les outils MCP.

Maintenir la fiabilité du workflow

Quelques habitudes maintiennent un workflow d'agent en bonne santé en production. Ajoutez une vérification après chaque exécution pour qu'un crawl échoué soit visible plutôt que de produire silencieusement une ligne vide. Espacez vos requêtes quand vous bouclez sur de nombreuses URLs plutôt que de les envoyer toutes en même temps. Persistez la sortie structurée quelque part, une base de données ou même une feuille de calcul, pour pouvoir revenir en arrière et comparer dans le temps. Et affinez le prompt par cible si nécessaire : une instruction générique sur des sites très différents donne généralement des résultats plus faibles que quelques lignes spécifiques au site.

Quand un agent signale qu'"aucun outil n'a été utilisé", cela signifie presque toujours que le modèle n'était pas sûr qu'il devait crawler. Resserrer le message système et s'assurer que l'URL est clairement dans la tâche résout le problème. Pour les problèmes de connexion, vérifiez que le serveur MCP est en cours d'exécution, confirmez que le token est défini dans l'environnement, et listez les outils en premier pour prouver que la poignée de main fonctionne avant de déboguer le modèle.

Foire aux questions

Qu'est-ce que le Crawlbase Web MCP et comment un agent l'utilise-t-il ?

Le Crawlbase Web MCP est un serveur Model Context Protocol qui publie des outils d'accès web, principalement un outil crawl, à tout agent IA compatible MCP. L'agent se connecte au serveur, découvre les outils, et les appelle quand il a besoin du contenu d'une page en direct. Chaque appel s'appuie sur la Crawling API, de sorte que l'agent reçoit du contenu rendu et propre sans écrire de code de scraping.

Ai-je besoin du token normal ou du token JS pour les workflows d'agent ?

Utilisez le token JS pour le travail d'agent. Le token normal récupère le HTML statique, qui sur les sites modernes côté client est un shell vide. Le token JS rend la page dans un vrai navigateur avant de la retourner, de sorte que le contenu que lit l'agent contient réellement les données. Vous obtenez les deux tokens depuis le tableau de bord Crawlbase après vous être inscrit.

Quels agents et plateformes IA fonctionnent avec le Crawlbase Web MCP ?

Tout client compatible MCP fonctionne, notamment Claude Desktop, Cursor, Windsurf, et les plateformes d'agents comme n8n, ainsi que les agents personnalisés que vous construisez avec une bibliothèque client MCP. Tant que le client peut se connecter au serveur et appeler des outils, il peut utiliser les outils de crawl Crawlbase.

L'agent peut-il scraper des sites à forte charge JavaScript sans configuration supplémentaire ?

Oui. L'outil crawl rend JavaScript automatiquement via la Crawling API, de sorte que l'agent reçoit du contenu entièrement rendu sans que vous n'exécutiez Puppeteer ou Selenium. Pour les pages qui se chargent tardivement, passez ajax_wait et un page_wait plus grand dans les arguments d'outil et l'API attend que le contenu apparaisse.

Comment cela évite-t-il d'être bloqué ?

Les outils MCP passent par la Crawling API, qui fait tourner les IPs résidentielles, gère les empreintes de navigateur, et traite les défis anti-bots et les tentatives côté serveur. L'agent ne voit jamais cette mécanique ; il récupère simplement du contenu propre. Maintenez votre taux de requêtes raisonnable quand vous bouclez sur de nombreuses URLs et le workflow reste en bonne santé.

En quoi est-ce différent de donner à l'agent un simple outil de requête HTTP ?

Un outil HTTP brut retourne ce que le serveur envoie, ce qui sur la plupart des sites modernes est un shell non rendu ou un blocage. L'outil Crawlbase MCP rend la page derrière une IP de confiance et retourne du contenu terminé dès le premier appel, de sorte que l'agent passe ses tours à raisonner sur de vraies données plutôt qu'à réessayer des récupérations échouées.

IK

Ian Kalvin

Ingénieur support technique · Crawlbase

Ingénieur support technique chez Crawlbase, il écrit depuis la première ligne de ce qui casse réellement en production, sur les configurations de scraping et de proxys.

NZ

Neil Zamora

Architecte senior · Crawlbase

Architecte senior chez Crawlbase, axé sur les systèmes derrière le crawling à grande échelle : rotation de proxys, résilience anti-bot et les API qui masquent cette complexité.