Scraping, API ou MCP: o trade-off de fontes de dados que define seu agente

Você está construindo um agente que precisa ler preço, review e estoque de uma loja externa. Bate o primeiro problema: de onde vem esse dado?

Tem três caminhos. Scraping. API oficial. Servidor MCP. Cada um parece resolver a mesma coisa. Não resolve.

Esse post é sobre o trade-off que define se o seu agente vai aguentar produção ou virar lenda interna na próxima reunião de incidente.

TL;DR

• O que é: comparação prática entre scraping, API oficial e MCP como fontes de dados para agentes em casos de e-commerce (preço, review, estoque).
• Stack/Modelos: agnóstico — vale para Claude, GPT, Gemini, Llama. Os exemplos citam Shopify Storefront MCP e eBay Browse API.
• Custo/Acesso: depende — scraping cobra por volume, API costuma ser grátis com limites, MCP varia por servidor.
• Decisão central: raramente é "um vence". Quase sempre é híbrido com fronteira clara.

O contexto: por que essa decisão virou o gargalo dos agentes

Em novembro de 2024, a Anthropic lançou o Model Context Protocol. Em dezembro de 2025, doou o protocolo para a Agentic AI Foundation no Linux Foundation, com Anthropic, Block e OpenAI cofundando. No fim de 2025 já eram mais de 97 milhões de downloads mensais dos SDKs e 10 mil servidores MCP em produção.

Tradução: o MCP virou padrão de fato em integração de dados para agentes em pouco mais de um ano.

Isso não aposentou nem scraping nem API. Aposentou o argumento preguiçoso de "vou usar X porque é o que tem".

A pergunta agora é arquitetural. Para cada fonte de dado que seu agente consome, você está escolhendo entre três contratos diferentes com o mundo. E cada contrato tem cláusula de letra miúda.

Scraping: flexível, completo, frágil

Scraping é abrir o navegador na marra. Você baixa o HTML, extrai o que importa, ignora o resto.

O que ele te dá que nada mais dá:

• Tudo que aparece para um humano. Preço de oferta relâmpago, badge de "últimas unidades", contagem de avaliações, ordem dos resultados na busca, snippet de review com 5 estrelas em destaque.
• Histórico arbitrário. Você roda o crawler todo dia às 9h e em três meses tem uma série temporal que API nenhuma te entrega de graça.
• Independência de fornecedor. Não tem rate limit oficial, não tem deprecação anunciada por e-mail, não tem termos de uso te obrigando a marcar "powered by".

O que ele te tira:

• Fragilidade estrutural. Marketplace troca o nome de uma classe CSS, seu pipeline quebra. Bright Data publica taxa de sucesso de 98,44% em benchmark — o que é excelente para um provedor pago, e ainda assim significa que 1 em cada 60 páginas falha silenciosamente.
• Custo operacional invisível. Proxy residencial, rotação de user-agent, headless browser, captcha solver. Cada uma dessas peças quebra em horários diferentes.
• Risco jurídico em zona cinza. Termos de uso de quase todo grande marketplace proíbem scraping não autorizado. Você decide quanto dessa exposição quer tomar.

from playwright.sync_api import sync_playwright

def scrape_price(url: str) -> dict:
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        page = browser.new_page()
        page.goto(url, wait_until="networkidle")

        price = page.locator('[data-testid="product-price"]').inner_text()
        stock = page.locator('[data-testid="stock-status"]').inner_text()

        browser.close()
        return {"price": price, "stock": stock}

Esse código funciona hoje. Funciona amanhã. Quebra na quinta-feira porque alguém renomeou data-testid="product-price" para data-test="price-tag". Você não vai receber um e-mail avisando.

API oficial: estável, oficial, limitada

API oficial é o contrato formal. O fornecedor te entrega um endpoint, um schema e um SLA.

O que ela te dá:

• Dados estruturados, versionados, documentados. Você sabe o que vai vir antes de chamar.
• Estabilidade. Quando muda, há changelog, deprecation window, e geralmente uma versão N-1 disponível.
• Permissão explícita. Você está dentro dos termos de uso. Pode mostrar para cliente, pode escalar, pode falar em conferência.

O que ela te tira:

• O fora-do-script. A API expõe o que o produto da empresa decidiu expor. O Browse API do eBay tem teto de 10.000 itens por result set — para monitoramento de categoria inteira, isso é restrição, não detalhe.
• Latência de roadmap. Aquele campo novo que apareceu na página do produto na semana passada? Pode demorar trimestres para aparecer na API. Ou nunca aparecer.
• Contagem de chamada. Rate limits são reais e geralmente apertados para tier gratuito. Em escala você paga, e às vezes paga caro.

import requests

def get_price_via_api(item_id: str, token: str) -> dict:
    r = requests.get(
        f"https://api.ebay.com/buy/browse/v1/item/{item_id}",
        headers={"Authorization": f"Bearer {token}"},
    )
    r.raise_for_status()
    data = r.json()
    return {
        "price": data["price"]["value"],
        "currency": data["price"]["currency"],
        "estimated_availability": data.get("estimatedAvailabilities", []),
    }

Isso aqui não quebra na quinta. Mas se o produto que você quer monitorar está em uma categoria de leilão que a API não cobre, você não tem para onde correr.

MCP: padronizado, integrado, específico

MCP é a camada que faltava. Em vez de você escrever um adapter por fornecedor, o fornecedor expõe um servidor MCP e qualquer agente que fala MCP conversa com ele. A especificação 2025-11-25 define três primitivos: tools (ações executáveis), resources (dados de leitura) e prompts (templates).

O Shopify, por exemplo, já enviou quatro servidores MCP até março de 2026: Dev, Storefront, Customer Account e Checkout. O Storefront MCP expõe busca em linguagem natural, gestão de carrinho, políticas e tracking de pedido — tudo via tools nomeados que o agente chama direto.

O que ele te dá:

• Contrato pensado para LLM, não para integração machine-to-machine genérica. Tools têm nome semântico, parâmetros tipados, descrição que o modelo entende.
• Plug-and-play real. Carregou o servidor no host (Claude Desktop, Cursor, seu próprio agente), o agente já vê as tools.
• Composição entre fontes. Cinco servidores MCP carregados ao mesmo tempo, o agente decide qual chamar.

O que ele te tira:

• Nem todo fornecedor tem servidor MCP. E os que têm, expõem o que decidiram expor — mesma limitação política da API.
• Maturidade desigual. O Shopify Catalog API ganhou semantic search e embeddings nativos, mas a maioria dos servidores MCP de e-commerce ainda é wrapper fino sobre REST.
• Você ainda paga o custo da integração específica do fornecedor — só que agora ele pagou por você.

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def search_products(query: str):
    params = StdioServerParameters(command="shopify-mcp", args=["--store", "minha-loja"])
    async with stdio_client(params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            result = await session.call_tool(
                "search_products",
                arguments={"query": query, "limit": 20},
            )
            return result.content

Note o nível de abstração. Você não está montando query string, parsing JSON, lidando com paginação. Está chamando uma tool. O agente também faria isso direto, sem sua mediação.

A matriz: scraping, API ou MCP por caso de uso

Aqui é onde a teoria encontra a planilha de incidente.

Preço de produto

Default: comece pela API se existir. Caia para scraping no que ela não cobre. Substitua por MCP quando o fornecedor publicar.

Review e reputação

Default: scraping com cuidado jurídico. Reviews são o caso clássico onde a API te dá menos do que o usuário humano vê.

Estoque e disponibilidade

Default: MCP se o fornecedor tem e o seu fluxo é agêntico. API se você é parceiro. Scraping se você é o terceiro de fora.

Mão na massa: o modelo híbrido na prática

A resposta honesta para "qual usar?" é: provavelmente os três, com fronteira clara.

Estrutura que funciona em produto real:

1. Camada de fonte primária. API oficial ou MCP do fornecedor para tudo que é estruturado e cobre o caso de uso. Esse é o seu chão estável.
2. Camada de complemento. Scraping cirúrgico para os campos que a fonte primária não expõe — tipicamente conteúdo de review, sinal de urgência, badge dinâmica.
3. Camada de fallback. Scraping de página inteira como plano B quando a API cai, com TTL curto e flag explícita de "dado é fallback".

async def get_product_signal(product_id: str) -> dict:
    try:
        primary = await mcp_client.call_tool("get_product", {"id": product_id})
    except (TimeoutError, ToolError):
        primary = await api_fallback(product_id)

    try:
        review_content = await scraper.fetch_reviews(product_id, limit=10)
    except ScrapeError:
        review_content = []

    return {
        "structured": primary,
        "review_signal": review_content,
        "source_quality": "primary+enrichment" if review_content else "primary_only",
    }

O importante não é o código. É o source_quality no retorno. O agente que consome isso precisa saber a confiança do dado, porque cada fonte tem fragilidade diferente.

Limitações e pontos de atenção

• Scraping em produção é um sistema vivo. Você precisa de monitoramento de schema (alerta quando o seletor para de bater), retentativa exponencial, rotação de IP, e um humano em standby para os dias que o site muda layout.
• API tem rate limit que aparece em horário ruim. Sempre cacheie. Sempre tenha plano para 429.
• MCP é jovem. Specs ainda mudam. A versão estável atual é a 2025-11-25, mas conte com breaking changes em servidores menos maduros. Pin de versão é obrigatório.
• Termos de uso não são detalhe. Antes de scrapear concorrente, leia os termos. Antes de redistribuir dado de API, leia os termos. Antes de pôr cliente em cima do agente, leia os termos.
• Custo total de propriedade muda em escala. Em piloto, scraping é o mais barato. Em produção com 10k requisições/min, API ou MCP costumam vencer porque você não paga proxy nem operação de pipeline frágil.

Não existe escolha sem cláusula. Existe escolha consciente da cláusula que você está assinando.

CTA

Se você está construindo agente que cruza dados de várias fontes e quer trocar ideia com gente que está lidando com o mesmo trade-off em produção, o lugar é o Clã Beer & Code. Lá rola discussão técnica sobre arquitetura de agente, MCP, RAG e produto real — sem hype, com gente colocando coisa em produção e voltando para contar o que quebrou.

FAQ rápido

Posso usar scraping e API ao mesmo tempo no mesmo produto? Pode e provavelmente deve. API para os campos estáveis, scraping para o que ela não cobre. O cuidado é deixar explícito no schema interno qual campo veio de onde, para tratar fragilidade diferente.

MCP substitui API REST? Não. MCP roda em cima da API, geralmente. O servidor MCP é um wrapper que expõe a API para LLMs com semântica de tool. A API REST continua existindo para integração machine-to-machine clássica.

Vale a pena escrever meu próprio servidor MCP em vez de chamar a API direto? Vale se você tem múltiplos agentes consumindo a mesma fonte, ou quer que o LLM decida sozinho quando chamar. Para um agente único e específico, chamar API direto via tool tradicional ainda é mais simples.

Como saber se um marketplace tem MCP oficial? Olhe o registro público no GitHub do Model Context Protocol e nos hubs comunitários. Se não tem, dá para construir o seu envolvendo a API pública — é literalmente o caso de uso original.

Conclusão

Scraping, API e MCP não são alternativas excludentes. São camadas com contratos diferentes para resolver o mesmo problema com fragilidades diferentes.

Dev sênior não escolhe ferramenta. Escolhe trade-off. Para preço, review e estoque, o trade-off muda por caso de uso, por fornecedor e por escala.

O agente que aguenta produção é aquele que sabe qual fonte está consumindo, com qual confiança, e o que faz quando essa fonte cai. O resto é hype.