Utiliser un résultat MCP de CAPTCHA dans un agent de navigation

1. 1.

   Configurez le serveur MCP local

   Suivez les instructions de configuration MCP pour lancer solvethree-mcp via npx. Il s’agit d’un serveur stdio local, pas d’un point de terminaison hébergé. Fournissez SOLVETHREE_API_KEY et SOLVETHREE_PROXY via l’environnement de l’hôte ; ne placez pas d’identifiants dans le prompt de l’agent.

2. 2.

   Vérifier les outils disponibles et le profil de site

   Appelez solvethree_capabilities pour examiner les fonctionnalités disponibles. Pour reCAPTCHA Enterprise, l’espace de travail doit déjà disposer d’un profil actif pour le nom d’hôte, l’action de capture et le type de reCAPTCHA prévus. Transmettre site et action à un outil de création ne crée pas ce profil. Utilisez Profils de site si la configuration reste à faire.

3. 3.

   Confirmer que le navigateur peut soumettre la requête correspondante

   Le navigateur doit prendre en charge le même proxy fixe ainsi que les valeurs userAgent et secChUa renvoyées. Il doit également conserver les cookies, les champs CSRF et les exigences de session de l’application. Si l’outil de navigation ne permet pas de configurer ces éléments, arrêtez-vous avant de payer une résolution plutôt que d’utiliser une session de navigateur sans rapport.

Pour l’outil MCP reCAPTCHA, l’unique proxy provient de SOLVETHREE_PROXY, et non des arguments de l’outil. Conservez ce même proxy pour la soumission par le navigateur. L’hôte reçoit des données de solution confidentielles : n’incluez donc pas les jetons ni les identifiants du proxy dans les rapports courants de l’agent.

Utilisez cette instruction une fois le serveur MCP et le navigateur configurés. Fournissez le nom d’hôte cible et l’action d’exécution issus de la requête de l’application. solvethree_create_recaptcha utilise Enterprise v3 par défaut ; ses arguments obligatoires sont site, action et requestId.

Use the already-configured solvethree MCP server for one reCAPTCHA Enterprise task.
The target hostname must have an active workspace profile before creation.
1. Keep one requestId for this logical task. Ask before starting another paid task.
2. Call solvethree_create_recaptcha with site, action and that requestId.
   The server reads its target proxy from SOLVETHREE_PROXY.
3. Save the returned id. Call solvethree_get_task for that id while pending/solving,
   stopping at ready, failed or the agreed deadline. Never poll by creating again.
4. If ready, submit solution.token using the application’s actual token parameter.
   Use the returned userAgent/secChUa and the same pinned proxy in the browser.
   Keep the application’s cookies, CSRF fields and session requirements.
5. Read the application response. Report task ID and outcome, not secret solution data.
If the browser tool cannot configure that proxy and identity, stop and explain the
missing capability instead of claiming it submitted an equivalent request.

L’id de tâche enregistré sert à solvethree_get_task ; ce n’est pas la valeur à soumettre au site web. pending et solving signifient qu’il faut continuer à attendre dans le délai convenu. Seul ready contient une solution utilisable. Avec failed, lisez errorCode et error, puis cessez d’interroger cette tâche.

Il n’existe pas d’étape universelle de remplissage automatique. Identifiez la requête de l’application qui utilise le résultat, puis employez le champ de solution correspondant. Pour chaque résultat ci-dessous, utilisez l’identité de navigateur renvoyée et le proxy ayant fonctionné pour la cible prévue.

Après la soumission, examinez la réponse de l’application. Une tâche ready signifie qu’une solution a été générée, pas que la cible l’a acceptée. Si la cible la rejette, examinez d’abord la requête sortante : confirmez que le bon jeton, cookie ou les bons en-têtes ont été envoyés, avec le proxy, l’identité et la session applicative correspondants. Indiquez l’identifiant de tâche et le résultat côté application sans exposer la solution.

Générez un requestId par tâche logique et conservez-le avec les paramètres d’origine. Il doit contenir 1–64 lettres ASCII, chiffres, traits de soulignement ou traits d’union. Si la création dépasse le délai avant que vous receviez un id, répétez la même requête de création avec le même requestId et des paramètres inchangés pour retrouver la tâche existante. Si vous disposez déjà de l’id de tâche, utilisez solvethree_get_task.

Ne modifiez pas les paramètres en réutilisant cet identifiant : cela provoque un conflit. Ne générez pas un nouvel identifiant simplement parce qu’une réponse a été perdue ou que le délai d’interrogation a expiré. Aucun de ces événements ne prouve que la tâche d’origine a échoué.

Chaque appel de création MCP produit au maximum une tâche, mais cela n’impose aucune limite de dépenses à l’agent. Exigez une approbation avant de lancer une autre tâche logique. En cas d’échec définitif, examinez errorCode et error avant de décider si une requête corrigée est justifiée ; les résolutions échouées sont remboursées. Une erreur de requête est un problème distinct d’une tâche dont l’état est failed.