Exécuter le serveur MCP de solvethree dans Docker

Enregistrez ceci dans Dockerfile. Ce fichier installe le paquet officiel sur Node 22, passe à l’utilisateur node sans privilèges root et lance solvethree-mcp comme point d’entrée du conteneur. Les commandes de construction et d’exécution figurent ci-dessous.

FROM node:22.23.4-alpine
RUN npm install --global https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz
USER node
ENTRYPOINT ["solvethree-mcp"]

# Build: docker build -t solvethree-mcp-local .
# Forward variables already set in the host; do not add their values to this file.
# Run: docker run --rm -i -e SOLVETHREE_API_KEY -e SOLVETHREE_PROXY solvethree-mcp-local

Avant de l’exécuter, définissez SOLVETHREE_API_KEY avec la clé API de votre espace de travail et SOLVETHREE_PROXY avec votre proxy dans l’environnement qui lance Docker. Chaque -e NAME transmet une variable existante ; il ne fournit pas de valeur. Ne placez pas d’identifiants dans le Dockerfile ni dans l’image.

L’image est construite localement sous le nom solvethree-mcp-local ; aucun compte Docker Hub n’est nécessaire. Son exécution ne crée pas de point de terminaison MCP hébergé et n’ajoute pas d’automatisation du navigateur.

Configurez un serveur stdio dans votre hôte MCP. Utilisez Docker comme commande, et non solvethree-mcp : le point d’entrée de l’image lance l’exécutable dans le conteneur.

N’ajoutez pas -t. L’hôte a besoin de stdin et stdout du conteneur pour JSON-RPC. --rm supprime le conteneur à son arrêt.

Les deux variables d’environnement doivent être accessibles au processus de l’hôte MCP. Les définir dans un terminal ne sert à rien pour un hôte lancé ailleurs, sauf s’il en hérite. Si l’hôte limite la transmission des variables d’environnement, autorisez les deux noms.

Pour une configuration TOML de type Codex, utilisez la table mcp_servers.solvethree avec la commande et les arguments ci-dessus. Incluez les deux noms de variables dans env_vars, définissez startup_timeout_sec sur 60 et tool_timeout_sec sur 100. Consultez la documentation de l’intégration MCP pour connaître le contrat sous-jacent du serveur.

1. 1.

   Vérifier les outils disponibles

   Appelez solvethree_capabilities après la connexion. Le serveur expose des outils de résolution et de récupération des tâches ; il ne pilote pas de navigateur et ne remplit pas de formulaires.

2. 2.

   Préparer le profil reCAPTCHA

   Pour reCAPTCHA, configurez un profil actif dans Profils de site avant de demander une résolution. Faites correspondre le nom d’hôte, l’action de capture et le type de reCAPTCHA ; ne supposez pas qu’un seul profil de domaine couvre toutes les actions. L’envoi d’une tâche ne crée pas de profil. Le guide de configuration des profils explique ce prérequis.

3. 3.

   Créer une seule tâche logique

   Appelez solvethree_create_recaptcha avec site, action et un requestId ; recaptchaType et waitMs sont facultatifs. Cet outil lit son unique proxy depuis SOLVETHREE_PROXY. Chaque appel de création produit au plus une tâche. Si le délai de création expire, réutilisez le même ID de requête avec des paramètres inchangés pour récupérer la tâche existante plutôt que d’en créer une autre.

4. 4.

   Attendre un résultat utilisable

   Si la tâche est pending ou solving, récupérez-la avec solvethree_get_task. Seul le statut ready contient une solution utilisable. En cas de statut failed, arrêtez les interrogations et examinez errorCode et error avant de décider quoi modifier.

5. 5.

   Envoyer depuis votre application

   Pour reCAPTCHA, envoyez solution.token, et non l’ID de la tâche. Utilisez l’identité renvoyée dans userAgent et secChUa avec le proxy qui a permis la résolution. Une tâche prête signifie qu’une solution a été générée, pas que la cible a accepté la requête de votre application.

L’hôte MCP reçoit des données de solution privées. Ne les incluez pas dans les journaux partagés ; votre application reste responsable de leur envoi à la cible prévue.