> ## Documentation Index > Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Référence des outils MCP Data Hub > Les six outils du MCP général Data Hub et le flux standard pour chercher, exécuter et récupérer les résultats d'une Data App. Cette page décrit le **MCP général Data Hub**. Il aide d'abord un agent à découvrir une Data App adaptée, puis lit le contrat à jour de l'application et l'exécute. Il utilise les mêmes capacités Data Hub que les tutoriels « choisir d'abord une application spécifique, puis se connecter ». La seule différence est le moment où l'application est choisie. Le nombre, les noms, les éditeurs, les prix, les entrées et les sorties des Data Apps changent en continu. Les outils du protocole MCP sont relativement stables. Cette page se concentre donc sur les contrats des outils et le flux général, et ne traite aucun instantané du catalogue comme une liste durable. ## Deux niveaux de capacité | Niveau | Contenu | Utilisation | | -------------------- | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | **Niveau protocole** | Six outils : chercher, obtenir les détails, exécuter, obtenir le statut, obtenir le résultat et annuler l'exécution | Un flux stable pour l'intégration par des agents ou des systèmes | | **Niveau données** | Capacité, prix, champs, visibilité et mode d'exécution de chaque Data App | Chercher et lire les détails à jour avant chaque appel | Pour une intégration à long terme avec une application fixe, notez son `app_id`. `namespace/app_name` référence aussi une application, mais peut cesser de fonctionner si l'éditeur ou l'application est renommé. ## Les six outils MCP ### `search_data_apps` : chercher dans le catalogue Découvrez des Data Apps avec des mots-clés métier. `query` accepte des mots-clés dans n'importe quelle langue. Laissez-le vide pour parcourir le catalogue qui vous est visible. Vous pouvez aussi filtrer avec `type` pour les applications de collecte ou de consultation (`data`) et de traitement (`transform`), et avec `scope` pour `all`, `public`, `private` ou `shared`. | Paramètre | Description | | ----------------- | ------------------------------------------------------------- | | `query` | Mots-clés métier optionnels. Liste le catalogue s'il est vide | | `type` | Optionnel : `data` ou `transform` | | `scope` | Périmètre de visibilité optionnel, `all` par défaut | | `offset`, `limit` | Pagination. `limit` va de `1-20`, `5` par défaut | Chaque carte de résultat comprend l'`app_id`, le nom, le résumé, le mode d'exécution (`sync` / `async`), des indications d'entrée et de sortie, le prix de départ et la visibilité. Cherchez et comparez d'abord. N'exécutez pas avant confirmation. ### `get_data_app_details` : lire le contrat complet Appelez cet outil avant d'exécuter. Transmettez un `app_id` ou `/` pour obtenir : * `input_schema` : le JSON Schema standard que cette exécution doit respecter. * `output_schema` : les champs qui peuvent être retournés. * `knowledge` : limites de la capacité, latence attendue et points d'attention. * `pricing` : description de la facturation. * `examples` : exemples d'entrées à utiliser comme point de départ. L'approche la plus sûre consiste à copier un `input` depuis `examples` et à l'ajuster. Ne devinez pas les noms de champs d'après le titre de la page, les descriptions du chat ou d'anciennes tâches. ### `run_data_app` : lancer une exécution Transmettez `app`, un `input` conforme à l'`input_schema` et, si nécessaire, `max_records` pour plafonner le nombre de résultats. Si l'entrée ne correspond pas au contrat, l'outil retourne immédiatement `[invalid-input]` et signale le champ problématique. Les valeurs de retour courantes incluent `run_id`, `state`, `progress`, `usage`, `billing` et `next_step`. Utilisez un petit `max_records` lors du premier essai pour vérifier les données, la durée et le coût. ### `get_run_status` : vérifier le statut de l'exécution Transmettez un `run_id` pour vérifier la progression, les détails d'échec, l'utilisation et le coût, sans lire les données. Pour les tâches asynchrones, utilisez `wait_seconds` (`0-60`) pour un long polling. Attendez 60 secondes par appel plutôt que d'interroger rapidement sans pause. Les états courants sont `QUEUED`, `RUNNING`, `SUCCEEDED`, `PARTIALLY_SUCCEEDED`, `FAILED` et `CANCELLED`. En cas d'échec, consultez `error.code`, `error.category`, `error.message` et `error.retryable`. ### `get_run_result` : lire les résultats Lit au maximum 50 enregistrements par appel. Paginez avec `offset`, et utilisez `fields` pour demander un sous-ensemble de champs séparés par des virgules, comme `title,price,url`, afin que les champs volumineux inutiles n'encombrent pas la conversation. Lorsque la réponse contient un `handoff`, le résultat est volumineux ou inadapté à une pagination supplémentaire dans la conversation. Suivez la commande SDK ou REST indiquée dans le `handoff` pour exporter un fichier, plutôt que de faire déplacer le JSON complet par l'agent à répétition. ### `cancel_run` : annuler une exécution Transmettez un `run_id` pour annuler une tâche en attente ou en cours. Une tâche en cours peut prendre quelques secondes pour s'arrêter de façon coopérative. Les résultats partiels déjà produits sont conservés et peuvent encore être lus avec `get_run_result`. Seules les données produites sont facturées. ## Flux de travail standard ```text theme={null} theme={null} search_data_apps → get_data_app_details → run_data_app → get_run_status (async uniquement, long polling) → get_run_result → cancel_run (quand vous devez arrêter) ``` ### Applications synchrones et asynchrones | Mode d'exécution | Comportement | Recommandation | | ---------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | `sync` | Se termine en quelques secondes. Les petits résultats peuvent retourner `records` directement | Vérifiez d'abord le retour, puis continuez avec `next_step` | | `async` | Retourne immédiatement un `run_id` et exécute la véritable extraction en arrière-plan | Soumettez plusieurs cibles à la suite, puis attendez avec `get_run_status(wait_seconds=60)` | Recevoir un `run_id` pour une tâche asynchrone ne signifie pas que l'extraction a réussi. Confirmez l'état final avant de lire les résultats, et ne soumettez pas à nouveau la même cible à cause de l'attente. ## Comment travailler avec les Data Apps Les Data Apps sont les capacités de données concrètes de Data Hub. De nouvelles arrivent et les existantes changent : cette page ne tient donc aucune liste figée. Avant utilisation, cherchez avec `search_data_apps` et confirmez les entrées, sorties, prix et limites actuels avec `get_data_app_details`. ## Conseils de connexion et d'utilisation * **Application pas encore choisie** : suivez Connexion générale : choisir une application dans l'agent pour connecter d'abord le MCP Data Hub, puis chercher, comparer et confirmer. * **Application fixe utilisée à long terme** : utilisez Codex : connecter une application spécifique ou Claude Code : connecter une application spécifique pour réduire le périmètre des outils. * **Coûts ou gros volumes de données en jeu** : appelez d'abord l'outil de détails pour vérifier `pricing` et `examples`, testez avec un petit volume de données et traitez le `handoff` lorsque vous avez besoin d'un résultat volumineux. Le MCP général Data Hub est basé sur `https://mcp-v2.octoparse.com` et prend en charge la clé API ou OAuth. La configuration de connexion et les paramètres actuels sont ceux que génère la Data Hub Open Platform. Il est différent du serveur MCP de scraping Octoparse de la navigation principale. Ne mélangez pas leurs adresses, leur authentification ni leurs noms d'outils.