Añade solvethree MCP a Claude Desktop

Instala Node.js 22 en el equipo que ejecuta Claude Desktop. Ten a mano la clave de API de tu espacio de trabajo y una URL de proxy HTTP o HTTPS. El servidor MCP usa un proxy proporcionado mediante SOLVETHREE_PROXY; la herramienta de reCAPTCHA no acepta un argumento de proxy.

Para reCAPTCHA, crea primero un perfil activo en Perfiles de sitio. Configura el nombre de host del destino, la acción de captura y el tipo de reCAPTCHA que necesitas. Proporcionar un nombre de host y una acción a Claude no crea ese perfil. Consulta la configuración de perfiles de sitio si aún no está activo.

1. 1.

   Abre el archivo de configuración local

   En macOS, usa ~/Library/Application Support/Claude/claude_desktop_config.json. En Windows, usa %APPDATA%/Claude/claude_desktop_config.json.

2. 2.

   Añade el servidor de solvethree

   Usa la configuración siguiente. Si el archivo ya contiene mcpServers, añade la entrada solvethree dentro de él en lugar de sustituir los otros servidores. Sustituye ambos marcadores de variables de entorno de forma privada.

3. 3.

   Reinicia Claude Desktop

   Reinícialo después de guardar para que la aplicación anfitriona inicie el servidor con la nueva configuración.

{
  "mcpServers": {
    "solvethree": {
      "command": "npx",
      "args": [
        "--yes",
        "--package=https://solvethree.com/downloads/solvethree-sdk-0.1.0.tgz",
        "solvethree-mcp"
      ],
      "env": {
        "SOLVETHREE_API_KEY": "REPLACE_WITH_YOUR_WORKSPACE_KEY",
        "SOLVETHREE_PROXY": "http://USER:PASSWORD@YOUR_PROXY:PORT"
      }
    }
  }
}

Los args descargan el archivo del SDK oficial e inician su ejecutable solvethree-mcp como servidor stdio local. No hay ningún endpoint MCP alojado que debas introducir.

Empieza con solvethree_capabilities. Usa solvethree_get_task para recuperar una tarea existente. Ninguna de las dos operaciones es una solicitud para crear una resolución nueva.

• solvethree_create_recaptcha acepta site como nombre de host, action y requestId, con recaptchaType y waitMs opcionales. El tipo predeterminado es enterprise-v3; también se acepta v3.
• solvethree_create_kasada crea una tarea de Kasada. Actualmente, Kasada independiente admite destinos HTTPS en www.ticketmaster.com, no sitios web arbitrarios.
• solvethree_create_tmpt crea una tarea de TMPT. Las tareas de evento usan la URL del evento; las tareas de inicio de sesión usan la URL de entrada al inicio de sesión.

Da a Claude permiso explícito para crear una tarea para el destino y la acción acordados. Exige una nueva aprobación antes de que inicie otra tarea de pago, incluido un reemplazo tras un fallo o un rechazo del destino. El permiso para inspeccionar o consultar periódicamente una tarea no debe interpretarse como permiso para crear otra.

Cada herramienta de creación requiere requestId y crea como máximo una tarea. Conserva ese ID junto con las entradas originales. Si se agota el tiempo de espera de la creación, recupera la tarea repitiendo la misma solicitud con el mismo ID, o recupérala directamente si ya tienes su ID de tarea. Que se agote el tiempo de espera no demuestra que la creación haya fallado. Cambiar las entradas al reutilizar el ID genera un conflicto; usar un ID nuevo puede crear otra tarea.

Si el estado es pending o solving, sigue consultando la tarea existente. Solo ready contiene una solución utilizable. Si el estado es failed, deja de consultar y revisa errorCode y error; las resoluciones fallidas se reembolsan. No vuelvas a enviar automáticamente los mismos datos de entrada no válidos.

Claude recibe datos privados de la solución a través del host MCP. Haz que tu aplicación utilice el resultado para el destino previsto, con el proxy que permitió resolver la tarea y los valores userAgent y secChUa devueltos. No resuelvas mediante el proxy configurado para luego enviar la solución desde otra IP o con una identidad de navegador distinta.

Una tarea en estado ready significa que se ha generado una solución, no que el sitio web haya aceptado tu solicitud posterior. Si el destino la rechaza, revisa el token, la cookie o las cabeceras enviados, el proxy, la identidad del navegador y la URL de destino antes de autorizar otra resolución.