Cómo solucionar que las llamadas MCP de CAPTCHA usen la sesión de navegador incorrecta

Resumen

• Una herramienta MCP de CAPTCHA que acepta una URL no actúa automáticamente sobre la pestaña del navegador que tu agente ya controla.
• En la interfaz probada de capsolver-mcp 0.1.3, detect_captchas y solve_on_page aceptan page_url; ninguna expone un parámetro de página existente ni de sesión de navegador.
• Inspecciona el esquema de la herramienta anunciada antes de asumir que dos servidores MCP comparten un navegador.
• Mantén la página original bajo el propietario de navegador que ya la controla. Usa una integración que acepte esa página o enruta los parámetros y resultados documentados a través de tu propia aplicación.
• Confirma la tarea original de la aplicación después de manejar un desafío compatible. La respuesta de una herramienta por sí sola no confirma que se haya enviado un formulario o completado una consulta de datos.

Tu agente de navegador ha rellenado un formulario y ha encontrado un CAPTCHA. Llama a una segunda herramienta MCP con la URL de la página, recibe una respuesta y vuelve a una pestaña que sigue viéndose igual. La conexión que falta puede ser la propia sesión de navegador.

MCP hace que una herramienta sea invocable; no hace que todos los servidores conectados compartan objetos de navegador en vivo. El navegador que preparó el formulario y el navegador abierto por una herramienta basada en URL pueden ser distintos. CapSolver proporciona tanto herramientas MCP como un Core SDK de Python, así que elegir la interfaz correcta importa cuando un CAPTCHA aparece a mitad de una tarea existente.

Esta guía diagnostica ese traspaso concreto. Incluye una comprobación real del esquema MCP y observaciones desde un fixture local de navegador propio. No se resolvió ningún desafío de pago y no se afirma aceptación de formularios en producción.

¿Por qué la llamada al CAPTCHA MCP usa otro navegador?

Las herramientas MCP de navegador probadas crean su propio navegador a partir de una URL en lugar de recibir la página activa del agente.

La referencia de servicios MCP describe la detección basada en URL y la resolución en página. Comprobamos los esquemas anunciados del paquete instalado y la implementación de lanzamiento del navegador, y luego observamos sus solicitudes hacia un fixture local. Estas comprobaciones coinciden en el límite: suministrar la URL no conecta la herramienta con una pestaña ya en ejecución.

Esa distinción importa incluso cuando ambas páginas muestran la misma dirección. Un campo de formulario puede contener un valor sin enviar en una pestaña y estar vacío en otra. Una cookie disponible para un contexto de navegador no aparece automáticamente en un contexto no relacionado. La guía de contextos de navegador de Playwright explica el aislamiento entre contextos.

No infieras estado compartido solo porque los dos servidores de herramientas aparecen en la misma barra lateral del asistente. Sus herramientas pueden estar disponibles para el mismo modelo mientras que sus procesos de navegador siguen siendo independientes.

Inspecciona el esquema de la herramienta antes de cambiar el flujo

Inspecciona el esquema en vivo para identificar qué estado puede recibir realmente la herramienta.

Usa Python 3.12 para la comprobación reproducible siguiente. El entorno probado contenía capsolver-mcp 0.1.3, capsolver-core 0.1.1, MCP Python SDK 1.30.0 y Playwright 1.64.1. El repositorio oficial de MCP identifica el paquete del servidor; el MCP Python SDK proporciona el cliente usado para este diagnóstico.

Ejecuta estos comandos con el intérprete de Python que lanzará el servidor:

python -m pip install "capsolver-mcp[browser]==0.1.3" "capsolver-core==0.1.1" "mcp==1.30.0" "playwright==1.64.1"
python -m playwright install chromium

Guarda este pequeño diagnóstico como inspect_mcp.py y ejecútalo con ese mismo Python. Inicializa una conexión real por stdio, lee los esquemas y llama al registro de tipos soportados. A propósito pasa una clave de API vacía y nunca llama a métodos de resolución ni de saldo. Una resolución real de pago requiere una clave válida y un objetivo autorizado; este diagnóstico no prueba esa ruta.

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

async def main():
    server = StdioServerParameters(
        command=sys.executable,
        args=["-m", "capsolver_mcp"],
        env={"CAPSOLVER_API_KEY": ""},
    )
    async with stdio_client(server) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            result = await session.list_tools()
            for tool in result.tools:
                if tool.name in {"detect_captchas", "solve_on_page"}:
                    print(json.dumps({
                        "tool": tool.name,
                        "arguments": sorted(tool.inputSchema.get("properties", {})),
                        "required": tool.inputSchema.get("required", []),
                    }))
            registry = await session.call_tool("get_supported_captchas", {})
            print("registry_is_error:", bool(registry.isError))

asyncio.run(main())

Para la versión probada, la salida significativa fue:

{"tool": "detect_captchas", "arguments": ["page_url"], "required": ["page_url"]}
{"tool": "solve_on_page", "arguments": ["autofill", "page_url", "polling_interval", "timeout"], "required": ["page_url"]}
registry_is_error: False

La ausencia de un argumento de sesión es un motivo para inspeccionar la implementación, no una afirmación universal sobre todos los servidores MCP. Aquí, la inspección del paquete confirmó un nuevo navegador headless y página para cada llamada de navegador basada en URL. Vuelve a comprobar el esquema y el comportamiento al cambiar de versión.

Lo que mostró la prueba de navegador local

La prueba local demostró un límite de sesión sin pretender resolver un CAPTCHA.

Abrimos un fixture HTTP propio en un contexto de Playwright, establecimos una cookie inofensiva fixture_session e introdujimos una consulta de catálogo en un campo de texto. El fixture registraba si cada solicitud transportaba esa cookie. Después llamamos a la herramienta MCP real detect_captchas con la misma URL.

La solicitud del navegador original incluía la cookie marcadora. La solicitud del navegador MCP no. La página original seguía conteniendo la consulta introducida después de que la herramienta devolviera la respuesta. La detección devolvió una lista vacía en este fixture inerte; no era un desafío real de un proveedor y la prueba no mide la cobertura de detección.

Estas observaciones establecen algo más limitado y útil: la llamada MCP obtuvo la URL de forma independiente, mientras que la primera página permaneció intacta. No establecen resolución de pago, transferencia de tokens ni aceptación por parte de un sitio de destino. No se usaron cookies de producción, credenciales ni registros privados.

Para tu aplicación, reproduce la misma distinción con un marcador inofensivo en una página de pruebas que controles. Registra qué página posee la herramienta de navegador y qué página recibe el solver. Evita registrar contenidos reales de cookies o tokens de CAPTCHA en los logs de diagnóstico.

Canjea tu código de bonificación de CapSolver

Aumenta tu presupuesto de automatización al instante.
Usa el código de bonificación CAP26 al recargar tu cuenta de CapSolver para obtener un 5% de bonificación extra en cada recarga, sin límites.
Canjéalo ahora en tu Panel de CapSolver

Elige un traspaso que coincida con el propietario de tu navegador

Elige el traspaso según si tu aplicación puede acceder al objeto de página activo.

Tu aplicación de Python es la propietaria de la página de Playwright

El Core SDK acepta una página de Playwright existente para los métodos orientados a navegador. Los métodos documentados detect(page) y get_captcha_info(page) inspeccionan esa página; solve_on_page(page) realiza la secuencia documentada de resolución y auto-relleno para desafíos compatibles. La referencia del Core SDK describe estas interfaces y sus campos de resultado.

Mantén la página en tu propia aplicación y pasa el objeto existente en el punto de control del CAPTCHA. Crear una página nueva dentro del manejador cambia la operación que estás diagnosticando. Esto es una elección de implementación para aplicaciones que poseen su código de navegador, no una bandera de configuración que haga que la herramienta MCP basada solo en URL se conecte a una pestaña.

Esta guía verifica el límite de MCP, no una resolución de pago con el Core SDK. Antes de adoptar una resolución basada en página en producción, prueba por separado el tipo de desafío soportado y la condición de finalización de la aplicación en un objetivo autorizado.

Otro servidor MCP es el propietario del navegador

Cuando otro servidor es el propietario del navegador, usa las capacidades documentadas de ese servidor para inspeccionar la página actual y decidir si puede aplicar un resultado externo. No inventes un session_id compartido, argumento CDP ni handle de página que el esquema del solver no acepte.

La resolución en modo token puede devolver un resultado a partir de parámetros de desafío documentados, pero tu aplicación sigue necesitando una forma soportada de entregarlo a la página original. Si el propietario del navegador no puede hacerlo, registra la carencia de capacidad o deriva la tarea a una persona. Conectar ambos servidores no crea la operación que falta.

La tarea comienza intencionalmente desde una URL nueva

Una herramienta basada en URL puede ser adecuada para una inspección independiente en la que una página nueva sea exactamente lo que pretendías. Nombra esa tarea por separado del formulario pausado del agente. Una inspección correcta de la nueva página no debe informarse como finalización del formulario original.

La guía existente sobre reutilización de contextos de Playwright explica las instantáneas de almacenamiento y las páginas en vivo. El problema específico de MCP aquí está antes en la cadena: qué navegador recibe la llamada.

Continúa solo después de comprobar la tarea original

Continúa la tarea original solo después de que la página prevista y la respuesta de la aplicación confirmen que el siguiente paso es válido.

Mantén juntos el propietario del navegador, la operación actual y la condición de finalización. Después de que termine una resolución compatible, inspecciona de nuevo la página original. Confirma que el formulario o la consulta siguen representando la misma tarea y después realiza el envío o la navegación permitidos mediante la interfaz normal del propietario del navegador.

Para un agente de datos, el éxito podría significar que los identificadores de registros esperados y los campos requeridos están presentes en los datos devueltos. Para un flujo de trabajo de formulario, el éxito podría ser una confirmación de la aplicación vinculada a las entradas enviadas. Un resultado vacío de detección de CAPTCHA no es ninguno de esos resultados.

Si la página navegó o el desafío cambió durante la llamada, inspecciona la tarea actual antes de reutilizar cualquier resultado anterior. Evita emitir resoluciones de pago repetidas solo porque una pestaña no relacionada siga mostrando un widget. Mantén los estados no resueltos explícitos en lugar de dejar que el modelo los resuma como éxito.

Crea flujos de automatización fiables con CapSolver

Trata la propiedad del navegador como parte del contrato de integración del CAPTCHA. CapSolver puede proporcionar capacidades de resolución documentadas, mientras tu aplicación mantiene la responsabilidad sobre la página prevista y la tarea final. Empieza comprobando el esquema MCP real y luego prueba el traspaso que tu entorno de navegador soporta.

Preguntas frecuentes

P: ¿Dar a una herramienta MCP de CAPTCHA la misma URL reutiliza mi pestaña de navegador?

No, no en las herramientas basadas en URL de capsolver-mcp 0.1.3 probadas. El esquema en vivo y la prueba local de solicitudes mostraron una petición de navegador separada.

P: ¿Puedo pasar el ID de sesión de mi servidor de navegador a solve_on_page?

El esquema de la herramienta probada no acepta ese argumento. Solo usa las entradas anunciadas por el servidor instalado; un ID de sesión de otra herramienta no es automáticamente significativo aquí.

P: ¿autofill actualiza la pestaña original del agente?

No lo des por hecho. La herramienta basada en URL actúa sobre la página que abre. El auto-relleno en esa página no establece un cambio en una pestaña propiedad de otro proceso.

P: ¿El ejemplo resolvió un CAPTCHA real?

No. Verificó la conexión MCP, los esquemas de herramienta y la separación de sesiones de navegador usando un fixture inerte propio. La resolución de pago y la aceptación por parte de la aplicación requieren pruebas independientes.

P: ¿Qué pasa si mi herramienta de navegador no puede aplicar el resultado del solver?

Usa una integración basada en página soportada en una aplicación que sea propietaria del navegador, o pausa para intervención humana. No afirmes que dos conexiones MCP por sí solas proporcionan una capacidad de navegador que falta.