O Model Context Protocol resolveu primeiro a metade errada do problema, e isso não é uma crítica, é apenas a ordem em que as coisas aconteceram. O MCP nos deu uma forma limpa e padronizada de conectar um modelo de linguagem a ferramentas e dados. O que ele deliberadamente não faz é resolver o que acontece quando uma dessas ferramentas acessa a web aberta e a web aberta responde com um 403.
Se você já construiu ou operou um servidor MCP que busca URLs, faz scraping de páginas, acessa resultados de busca ou coleta dados ao vivo para um modelo, provavelmente já esbarrou nesse muro. O servidor funciona perfeitamente no seu laptop. Você o implanta em uma máquina na nuvem, aponta seu agente para ele e, de repente, metade das buscas retorna páginas de CAPTCHA, “acesso negado” ou redirecionamentos geográficos para o site do país errado. Nada no seu código MCP mudou. O IP mudou.
Este post é sobre essa lacuna: por que servidores MCP que buscam conteúdo web são bloqueados, por que isso não é um problema que o MCP deva resolver, e como uma camada de proxy residencial fecha essa lacuna com algumas linhas de código.
Uma revisão rápida de onde ocorre o acesso à web
O MCP tem uma separação clara de papéis. Um host (Claude Desktop, uma IDE, um runtime de agente) executa um cliente MCP, que conversa com um ou mais servidores MCP. Cada servidor expõe ferramentas, recursos e prompts. Quando o modelo decide usar uma ferramenta, a chamada flui host → cliente → servidor, o servidor realiza o trabalho de fato, e o resultado retorna pelo caminho inverso.
A parte importante para esta discussão: o servidor é onde ocorrem os efeitos colaterais reais no mundo. Quando você constrói uma ferramenta fetch, uma ferramenta search ou uma ferramenta scrape_page, a requisição HTTP de saída se origina do processo do servidor MCP, onde quer que esse processo esteja rodando. O modelo não faz a requisição. O host também não. Quem faz é o servidor.
Então o IP que o site de destino vê é o IP do servidor MCP. E esse é todo o problema.
Por que servidores MCP que buscam conteúdo web são bloqueados
Três fatores se acumulam, e se acumulam especificamente contra servidores MCP de uma forma que não acontece com um ser humano usando um navegador.
Seu servidor MCP quase certamente está em um IP de datacenter. Se você o implantou na AWS, GCP, Fly, Render, um VPS ou qualquer host na nuvem, seu IP de saída pertence a um ASN de provedor de hospedagem. Sistemas anti-bot (Cloudflare, Akamai, DataDome) tratam ASNs de datacenter como culpados até prova em contrário. Uma requisição de um IP da AWS para um site protegido é sinalizada antes mesmo de o servidor enviar um cabeçalho. Este é o maior motivo isolado pelo qual “funcionou localmente” se transforma em “está bloqueado em produção”: sua conexão em casa é residencial, sua máquina na nuvem não é.
O tráfego de agentes é intenso e concentrado. Um agente não navega como uma pessoa. Ele dispara uma sequência de requisições em uma janela curta, muitas vezes para o mesmo domínio, e depois fica em silêncio. De um único IP, esse padrão é lido como automação imediatamente. Escrevemos sobre o formato do tráfego de agentes de IA separadamente, mas a versão resumida é: limites de taxa e detecção comportamental que um humano nunca ativaria, um agente ativa constantemente, porque todo o tráfego vem de um único endereço.
Você não tem controle geográfico. Seu servidor MCP roda em uma região. Se o modelo precisa ver uma página de produto como um comprador alemão veria, um resultado de busca como um usuário de Tóquio, ou um preço como um cliente dos EUA, um servidor de região única fisicamente não consegue. O site geolocaliza o IP do servidor e entrega o conteúdo do país errado, silenciosamente. O modelo então raciocina sobre dados que acredita estarem corretos e não estão.
Nada disso é falha no seu servidor MCP. São propriedades de onde ele roda e como é estruturado. O MCP está fazendo exatamente o seu trabalho, transportando a chamada da ferramenta. Ele nunca foi feito para lavar o IP.
Por que isso não é responsabilidade do MCP resolver
Vale a pena ser explícito, porque às vezes as pessoas esperam que o protocolo ganhe uma funcionalidade que não vai chegar. O MCP é um protocolo para comunicação entre modelo e ferramenta. Ele padroniza como uma ferramenta é descrita, chamada, e como os resultados retornam. O transporte entre cliente e servidor (stdio, ou Streamable HTTP) diz respeito à infraestrutura do agente, não a como o servidor alcança a internet.
Como sua ferramenta fetch conversa com o mundo exterior é um detalhe de implementação do seu servidor, exatamente como qual biblioteca HTTP você usa ou como você analisa a resposta. O protocolo não deveria ditar isso, e não dita. O que significa que a camada de acesso à web é sua para adicionar. A boa notícia é que é uma camada pequena e bem compreendida: rotear as requisições de saída do servidor através de IPs residenciais.
A solução: um proxy residencial atrás da ferramenta de fetch
O padrão é simples. Em vez de a ferramenta do seu servidor MCP fazer uma requisição direta a partir do seu IP de datacenter, ela faz a requisição através de um gateway de proxy residencial. O site de destino vê um IP real de consumidor no país correto, com o perfil de confiança de uma conexão doméstica de verdade, e a requisição passa.
Aqui está um servidor MCP mínimo em Python com uma ferramenta fetch_url que roteia através do gateway Shifter. O esqueleto MCP é o FastMCP padrão; a parte que importa é a configuração de proxies no cliente HTTP.
import osimport httpxfrom mcp.server.fastmcp import FastMCP
mcp = FastMCP("web-fetch")
# One gateway endpoint, targeting encoded in the username.# Keep credentials in env, never in the tool definition.USER = os.environ["SHIFTER_USER"] # e.g. "customer-<id>"PASS = os.environ["SHIFTER_PASS"]GATEWAY = "p.shifter.io:443"
def proxy_url(country: str = "us") -> str: return f"http://{USER}-country-{country}:{PASS}@{GATEWAY}"
@mcp.tool()async def fetch_url(url: str, country: str = "us") -> str: """Fetch a URL through a residential IP in the given country.""" proxies = proxy_url(country) async with httpx.AsyncClient(proxy=proxies, timeout=30) as client: r = await client.get(url, follow_redirects=True) r.raise_for_status() return r.text
if __name__ == "__main__": mcp.run()Essa é toda a mudança. O modelo chama fetch_url("https://example.com/product", country="de"), a requisição sai por um IP residencial na Alemanha, e o site entrega a página em alemão para o que parece ser um comprador alemão. Troque o country e o modelo verá a mesma página pelos olhos de outro mercado, sem novo deploy e sem um segundo servidor.
O direcionamento geográfico é a parte de que os agentes mais precisam
O problema de bloqueio é o primeiro que as pessoas notam, mas o problema geográfico é o que silenciosamente corrompe os resultados. Um servidor MCP fixado em uma região é um LLM olhando para o mundo através de um buraco de fechadura.
Como o gateway Shifter codifica o direcionamento no nome de usuário, sua ferramenta fetch pode receber um argumento country (ou estado, cidade, até ASN) e deixar o modelo escolher a cada chamada. Isso transforma um servidor de região única em um servidor global. Um agente de pesquisa comparando preços entre mercados, um agente de QA de localização verificando como um site é renderizado em cinco países, um agente de monitoramento de SERP coletando resultados do Google como um usuário local, todos eles precisam exatamente disso e não conseguem obtê-lo de uma ferramenta de fetch comum hospedada na nuvem.
Para fluxos de múltiplas etapas em que o agente precisa do mesmo IP em várias chamadas (um login, seguido de uma sequência de páginas autenticadas), adicione uma sessão fixa incluindo um id de sessão e TTL no nome de usuário, o mesmo IP se mantém durante o tempo de vida do TTL:
def sticky_proxy_url(country: str, session: str, ttl: int = 600) -> str: return f"http://{USER}-country-{country}-sid-{session}-ttl-{ttl}:{PASS}@{GATEWAY}"Agora uma ferramenta browse_session pode manter uma identidade estável ao longo das etapas de uma tarefa, em vez de trocar de IP no meio do fluxo e disparar todas as verificações de sessão do site.
O que ter em mente
Uma camada de proxy não é um interruptor mágico de “nunca ser bloqueado”, e tratá-la assim é como as pessoas desperdiçam banda. Algumas observações práticas:
Faça cache de forma agressiva. Agentes buscam repetidamente as mesmas URLs constantemente. Um pequeno cache na frente da sua ferramenta de fetch reduz drasticamente a banda do proxy (e seu custo), e também é mais rápido para o modelo. Não passe pelo proxy uma requisição para a qual você já tem a resposta.
Repasse o país, não o fixe no código. Todo o valor está no controle geográfico por chamada. Faça de country um argumento de ferramenta que o modelo pode definir, com um padrão sensato, em vez de embutir uma região fixa no servidor.
Respeite o alvo. Um proxy muda de qual IP a requisição vem, não se você deveria estar fazendo a requisição. Honre o robots.txt onde for relevante, mantenha as taxas de requisição razoáveis, e não sobrecarregue um site só porque os bloqueios desapareceram. Nossa política de uso aceitável é a fonte de referência sobre o que é permitido.
Mantenha as credenciais fora do esquema da ferramenta. O nome de usuário e a senha do proxy ficam em variáveis de ambiente no servidor, nunca na definição da ferramenta que o modelo vê. O modelo deve escolher um país, não guardar a senha do seu gateway.
Datacenter é adequado para buscas não protegidas e neutras em relação à geografia. Se uma ferramenta só acessa suas próprias APIs ou endpoints públicos que não bloqueiam nem geolocalizam, ela não precisa do proxy. Reserve a camada residencial para as buscas na web aberta que de fato enfrentam bloqueio ou precisam de geolocalização. (Para uma comparação mais completa de quando cada tipo de IP se encaixa, veja proxies residenciais vs. proxies de datacenter.)
Perguntas frequentes
O MCP tem suporte a proxy embutido? Não, e não deveria ter. O MCP padroniza a comunicação entre modelo e ferramenta, não como uma ferramenta alcança a internet. O acesso web de saída é um detalhe de implementação do seu servidor. Você adiciona um proxy no nível do cliente HTTP dentro da ferramenta, exatamente como mostrado acima.
Por que não simplesmente rodar meu servidor MCP a partir de uma conexão residencial? Você poderia, mas isso não escala, não te dá controle geográfico por requisição, e amarra a confiabilidade do seu agente ao tempo de atividade e ao IP único de uma conexão doméstica. Um gateway de proxy residencial te dá um grande pool rotativo e direcionamento por país a cada chamada, sem hospedar nada em uma linha residencial.
Um proxy vai impedir completamente que meu agente seja bloqueado? Ele remove a maior causa (o IP de datacenter) e te dá controle geográfico, mas o comportamento ainda importa. Padrões de requisição intensos, cabeçalhos ausentes ou inconsistentes, e ignorar limites de taxa ainda podem te sinalizar. O proxy é necessário, não suficiente; combine-o com um comportamento de requisição sensato.
Isso funciona também com servidores MCP em TypeScript? Sim. O conceito é idêntico, configure seu cliente HTTP (fetch com um agent, axios, undici, got) para rotear através do gateway. O formato da URL do proxy e o direcionamento por requisição são os mesmos independentemente da linguagem.
O modelo pode escolher o país por requisição?
Sim, esse é o padrão recomendado. Exponha country (e opcionalmente estado/cidade) como um argumento de ferramenta com um valor padrão. O modelo o define com base na tarefa, e seu servidor o codifica no nome de usuário do proxy dinamicamente.
Rotear através de um proxy muda como a Shifter me cobra? Não. É o gateway residencial padrão com o preço usual por GB. Um servidor MCP é apenas mais um cliente se conectando ao mesmo endpoint. Banda é banda.
Conclusão
O MCP é uma resposta limpa para “como um modelo chama uma ferramenta”. Ele nunca foi feito para responder “como essa ferramenta alcança uma web aberta hostil a partir de um IP de datacenter sinalizado no país errado”. Essa segunda pergunta é real, é sua para responder, e a resposta é uma fina camada de proxy residencial atrás das suas ferramentas de fetch.
A configuração leva poucas linhas. O retorno é um servidor MCP cujas ferramentas web realmente funcionam em produção, retornam os dados do país correto, e não travam na primeira vez que um agente as aponta para um site protegido. Se você está construindo agentes conectados à web, comece com o gateway residencial e coloque-o atrás das suas ferramentas desde o primeiro dia, é muito mais fácil do que adaptar depois que os bloqueios começarem. Para mais sobre como dar aos agentes acesso confiável à web, veja os melhores proxies para agentes de IA que navegam na web.