Como corrigir chamadas MCP de CAPTCHA usando a sessão de navegador errada

Resumo

• Uma ferramenta MCP de CAPTCHA que aceita uma URL não opera automaticamente na aba de navegador que o seu agente já controla.
• Na interface testada capsolver-mcp 0.1.3, detect_captchas e solve_on_page aceitam page_url; nenhuma delas expõe um parâmetro de página existente ou de sessão de navegador.
• Inspecione o schema anunciado da ferramenta antes de assumir que dois servidores MCP compartilham um navegador.
• Mantenha a página original com o proprietário de navegador que já a controla. Use uma integração que aceite essa página ou encaminhe parâmetros documentados e resultados através da sua própria aplicação.
• Confirme a tarefa original da aplicação depois de lidar com um desafio compatível. Uma resposta da ferramenta, sozinha, não confirma que um formulário foi enviado ou que uma consulta de dados foi concluída.

Seu agente de navegador preencheu um formulário e chegou a um CAPTCHA. Ele chama uma segunda ferramenta MCP com a URL da página, recebe uma resposta e retorna para uma aba que ainda parece inalterada. A conexão faltando pode ser justamente a sessão de navegador.

MCP torna uma ferramenta chamável; ele não faz com que todos os servidores conectados compartilhem objetos de navegador ao vivo. O navegador que preparou o formulário e o navegador aberto por uma ferramenta de URL podem ser separados. A CapSolver fornece tanto ferramentas MCP quanto um Core SDK em Python, então escolher a interface certa importa quando um CAPTCHA aparece no meio de uma tarefa já em andamento.

Este guia diagnostica essa transferência específica. Ele inclui uma verificação real de schema MCP e observações a partir de um fixture local de navegador próprio. Nenhum desafio pago foi resolvido, e não se afirma aqui qualquer aceitação de formulário em produção.

Por que a chamada MCP de CAPTCHA usa outro navegador?

As ferramentas de navegador MCP testadas criam o próprio navegador a partir de uma URL, em vez de receberem a página ativa do agente.

A referência de serviço MCP descreve detecção e resolução em páginas baseadas em URL. Verificamos os schemas anunciados pelo pacote instalado e a implementação de abertura de navegador, depois observamos suas requisições para um fixture local. Essas verificações concordam sobre o limite: fornecer a URL não conecta a ferramenta a uma aba já em execução.

Essa distinção importa mesmo quando ambas as páginas exibem o mesmo endereço. Um campo de formulário pode conter um valor não enviado em uma aba e estar vazio em outra. Um cookie disponível em um contexto de navegador não aparece automaticamente em outro contexto não relacionado. A documentação de contextos de navegador do Playwright explica o isolamento entre contextos.

Não infira estado compartilhado só porque dois servidores de ferramentas aparecem na mesma barra lateral do assistente. As ferramentas podem estar disponíveis para o mesmo modelo enquanto seus processos de navegador permanecem independentes.

Inspecione o schema da ferramenta antes de mudar o fluxo

Inspecione o schema em tempo real para identificar qual estado a ferramenta realmente pode receber.

Use Python 3.12 para a checagem reproduzível abaixo. O ambiente testado continha capsolver-mcp 0.1.3, capsolver-core 0.1.1, MCP Python SDK 1.30.0 e Playwright 1.64.1. O repositório oficial MCP identifica o pacote do servidor; o MCP Python SDK fornece o cliente usado para este diagnóstico.

Execute estes comandos com o interpretador Python que irá iniciar o 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

Salve este pequeno diagnóstico como inspect_mcp.py e rode-o com o mesmo Python. Ele inicializa uma conexão real via stdio, lê os schemas e chama o registro de tipos suportados. Ele passa deliberadamente uma chave de API vazia e nunca chama métodos de resolução ou de saldo. Uma resolução paga real requer uma chave válida e um alvo autorizado; este diagnóstico não testa esse caminho.

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 a versão testada, a saída relevante foi:

{"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

A ausência de um argumento de sessão é um motivo para inspecionar a implementação, não uma afirmação universal sobre todo servidor MCP. Aqui, a inspeção do pacote confirmou um novo navegador headless e uma nova página para cada chamada de navegador baseada em URL. Verifique novamente o schema e o comportamento ao trocar de versão.

O que o teste com navegador local mostrou

O teste local demonstrou um limite de sessão sem fingir resolver um CAPTCHA.

Abrimos um fixture HTTP próprio em um contexto do Playwright, definimos um cookie inofensivo fixture_session e inserimos uma consulta de catálogo em um campo de texto. O fixture registrava se cada requisição carregava esse cookie. Em seguida, chamamos a ferramenta real detect_captchas do MCP com a mesma URL.

A requisição do navegador original incluía o cookie marcador. A requisição do navegador do MCP não. A página original ainda continha a consulta digitada após o retorno da ferramenta. A detecção retornou uma lista vazia nesse fixture inerte; ele não era um desafio de provedor real e o teste não mede cobertura de detecção.

Essas observações estabelecem algo mais estreito e útil: a chamada MCP buscou a URL de forma independente, enquanto a primeira página permaneceu intacta. Elas não estabelecem resolução paga, transferência de token ou aceitação pelo site alvo. Não foram usados cookies de produção, credenciais ou registros privados.

Para a sua aplicação, reproduza a mesma distinção com um marcador inofensivo em uma página de staging que você controla. Registre qual página a ferramenta de navegador possui e qual página o solucionador recebe. Evite registrar conteúdos reais de cookies ou tokens de CAPTCHA em logs de diagnóstico.

Resgate Seu Código de Bônus da CapSolver

Aumente instantaneamente seu orçamento de automação!
Use o código de bônus CAP26 ao recarregar sua conta CapSolver para obter 5% de bônus extra em cada recarga — sem limites.
Resgate agora no seu Painel da CapSolver

Escolha uma transferência que corresponda ao proprietário do navegador

Escolha a forma de transferência de acordo com a capacidade da sua aplicação de acessar o objeto de página ativo.

Sua aplicação Python é dona da página do Playwright

O Core SDK aceita uma página Playwright existente para métodos orientados a navegador. Os métodos documentados detect(page) e get_captcha_info(page) inspecionam essa página; solve_on_page(page) executa a sequência documentada de resolução e preenchimento de volta para desafios compatíveis. A referência do Core SDK descreve essas interfaces e seus campos de resultado.

Mantenha a página na sua própria aplicação e passe o objeto existente no ponto de checagem do CAPTCHA. Criar uma nova página dentro do handler muda a operação que você está diagnosticando. Isso é uma escolha de implementação para aplicações que controlam seu código de navegador, não uma flag de configuração que faça a ferramenta MCP baseada apenas em URL anexar-se a uma aba.

Este guia verifica o limite do MCP, não uma resolução paga via Core SDK em página. Antes de adotar uma resolução baseada em página em produção, teste separadamente o tipo de desafio suportado e a condição de conclusão da aplicação em um alvo autorizado.

Outro servidor MCP é dono do navegador

Quando um servidor diferente é dono do navegador, use as capacidades documentadas desse servidor para inspecionar a página atual e decidir se ele pode aplicar um resultado externo. Não invente um session_id compartilhado, argumento CDP ou identificador de página que o schema do solucionador não aceite.

A resolução em modo de token pode retornar um resultado a partir de parâmetros de desafio documentados, mas sua aplicação ainda precisa de um meio compatível de entregá-lo à página original. Se o proprietário do navegador não puder fazer isso, registre a lacuna de capacidade ou entregue a tarefa a uma pessoa. Conectar ambos os servidores não cria a operação que está faltando.

A tarefa começa intencionalmente por uma URL nova

Uma ferramenta baseada em URL pode servir para uma inspeção independente em que uma página nova é exatamente o que você deseja. Dê um nome separado a essa tarefa em relação ao formulário pausado do agente. Uma inspeção bem-sucedida da nova página não deve ser relatada como conclusão do formulário original.

O guia de reutilização de contexto do Playwright existente explica snapshots de armazenamento e páginas ao vivo. A questão específica de MCP aqui é mais cedo na cadeia: qual navegador recebe a chamada.

Continue apenas após verificar a tarefa original

Continue a tarefa original somente depois que a página pretendida e a resposta da aplicação confirmarem que o próximo passo é válido.

Mantenha juntos o proprietário do navegador, a operação atual e a condição de conclusão. Após uma resolução compatível terminar, inspecione novamente a página original. Confirme que o formulário ou consulta ainda representa a mesma tarefa e então realize o envio ou navegação permitidos através da interface normal do proprietário do navegador.

Para um agente de dados, sucesso pode significar que os identificadores de registro esperados e os campos obrigatórios estão presentes nos dados retornados. Para um fluxo de formulário, sucesso pode ser uma confirmação da aplicação vinculada aos dados enviados. Um resultado vazio de detecção de CAPTCHA não é nenhum desses resultados.

Se a página navegou ou o desafio mudou durante a chamada, inspecione a tarefa atual antes de reutilizar qualquer resultado anterior. Evite emitir resoluções pagas repetidas apenas porque uma aba não relacionada ainda exibe um widget. Mantenha estados não resolvidos explícitos em vez de deixar o modelo resumi-los como sucesso.

Construa fluxos confiáveis de automação com a CapSolver

Trate a propriedade do navegador como parte do contrato de integração de CAPTCHA. A CapSolver pode fornecer capacidades de resolução documentadas, enquanto sua aplicação mantém a responsabilidade pela página pretendida e pela tarefa final. Comece verificando o schema MCP real e depois teste a transferência que o seu ambiente de navegador suporta.

FAQ

P: Dar a mesma URL para uma ferramenta MCP de CAPTCHA reutiliza minha aba de navegador?

Não, não nas ferramentas baseadas em URL do capsolver-mcp 0.1.3 testado. O schema em tempo real e o teste de requisição local mostraram uma requisição de navegador separada.

P: Posso passar o ID de sessão do meu servidor de navegador para solve_on_page?

O schema da ferramenta testada não aceita esse argumento. Use apenas inputs anunciados pelo servidor instalado; um ID de sessão de outra ferramenta não é automaticamente significativo aqui.

P: autofill atualiza a aba original do agente?

Não assuma isso. A ferramenta baseada em URL opera na página que ela própria abre. O preenchimento de volta nessa página não estabelece uma mudança em uma aba controlada separadamente.

P: O exemplo resolveu um CAPTCHA real?

Não. Ele verificou a conexão MCP, os schemas das ferramentas e a separação de sessão de navegador usando um fixture próprio inerte. Resolução paga e aceitação pela aplicação requerem testes separados.

P: E se minha ferramenta de navegador não conseguir aplicar o resultado do solucionador?

Use uma integração baseada em página compatível em uma aplicação que seja dona do navegador, ou pause para um humano. Não afirme que duas conexões MCP, por si só, fornecem uma capacidade de navegador que está faltando.