🕷️ Build: scraping para CSV

Legenda: o caminho completo do build — o Firecrawl traz o conteúdo bruto do site, o agente organiza o que interessa e grava um CSV que abre direto numa planilha.

Novo aqui? Scraping é o nome técnico pra "extrair informação de uma página da web de forma automática". CSV é um arquivo de tabela simples (Comma-Separated Values — valores separados por vírgula) que qualquer planilha abre direto. Neste build você vai pedir pro agente ler uma página pública e entregar os dados dela organizados numa tabela — sem você tocar em código de scraping nenhum.

Este é o módulo "mão na massa" da Trilha 2: até aqui você aprendeu o que é o protocolo MCP (2.1), como um servidor MCP é organizado por dentro (2.2), como instalar e autenticar um (2.3), e como guardar instruções permanentes num cheat sheet (2.4). Agora tudo isso vira um resultado concreto — um arquivo de dados que você consegue abrir e mostrar pra alguém. É esse tipo de entrega tangível que separa "aprendi sobre MCP" de "usei MCP pra resolver um problema real".

Novo aqui? O Firecrawl é o servidor MCP que este build usa pra ler sites. Ele oferece quatro operações com propósitos bem diferentes — saber qual pedir (ou deixar o cheat sheet do módulo 2.4 guiar o agente) evita pedidos vagos e resultados vazios.

Um erro comum de quem está começando é pedir crawl quando na verdade queria extract — o resultado vem cheio de texto solto, difícil de organizar em colunas. Se o seu objetivo final é uma tabela (linhas e colunas, como um CSV), comece pensando em extract; se o objetivo é "ler o conteúdo" sem estrutura fixa, crawl ou scrape bastam.

Com o servidor MCP do Firecrawl já ligado (módulo 2.3), o build inteiro é um pedido bem descrito — o agente decide sozinho entre map/crawl/extract com base no que você pediu.

Objetivo: gerar um CSV com dados reais extraídos do site. Como verificar: abra produtos.csv numa planilha (Excel, Google Sheets, LibreOffice) e confirme que cada linha tem nome, preço e categoria preenchidos — sem células vazias em excesso.

Legenda: você nunca escreve as três chamadas técnicas — só descreve o resultado que quer. O agente é quem traduz o pedido em map, extract e a gravação do arquivo.

Dois erros que travam esse passo antes mesmo de começar: chave de API inválida ou expirada — o Firecrawl responde com um erro de autenticação e o agente não consegue nem tentar; o conserto é revisitar o módulo 2.3 e reautenticar. E endereço digitado errado — um https:// faltando ou um domínio com erro de digitação faz a primeira chamada falhar antes de qualquer scraping acontecer. Confira o endereço colado antes de rodar.

Legenda: o agente não desiste no primeiro "não achei nada" — ele tenta um esquema mais simples, depois recorre ao scrape bruto pra organizar manualmente, e só relata falha de verdade se as duas tentativas não funcionarem. É a auto-correção da Trilha 1, agora aplicada a scraping.

Às vezes o extract devolve uma lista vazia — a página pode ter uma estrutura diferente do esperado, ou os campos pedidos não existirem daquele jeito ali. É exatamente aqui que a auto-correção da Trilha 1 aparece na prática: um bom agente não desiste no primeiro "nada encontrado" — ele simplifica o pedido (menos campos), tenta de novo, e se ainda assim não der, recorre ao scrape bruto e organiza os dados manualmente a partir do texto completo.

Lista vazia não é o único jeito de o build falhar — outros dois erros comuns aparecem no meio do caminho. Um site que bloqueia scraping devolve uma resposta de erro (às vezes chamada de "403" ou "acesso negado") em vez de conteúdo — nesse caso, insistir não resolve; o site simplesmente não permite esse tipo de acesso automatizado, e o certo é procurar se ele oferece uma API pública própria ou desistir daquela fonte. E um limite de uso estourado (a cota mensal do seu plano do Firecrawl) faz toda chamada nova falhar até o próximo ciclo — o agente geralmente avisa isso na resposta de erro; se acontecer no meio de um crawl grande, é sinal de que valia a pena ter pedido menos páginas de uma vez.

Novo aqui? Cada chamada ao Firecrawl consome uma cota (um limite de uso mensal do seu plano) e alguns sites proíbem scraping nos termos de uso ou num arquivo chamado robots.txt. Antes de rodar um crawl grande, confira se o site permite e evite pedir volume maior do que você precisa de verdade.

O robots.txt é um arquivo simples que sites publicam na raiz do endereço (algo como exemplo.com/robots.txt) dizendo o que pode e o que não pode ser acessado por robôs automáticos — o Firecrawl costuma respeitar essas regras sozinho, mas vale saber que elas existem, porque explicam por que às vezes uma parte do site simplesmente não retorna nada. Se o dado que você quer envolve informação pessoal de terceiros (nomes, e-mails, telefones de pessoas físicas), trate com o mesmo cuidado que trataria qualquer outro dado sensível: pergunte se você realmente precisa daquele campo antes de incluí-lo no CSV, e nunca redistribua esse tipo de dado sem necessidade.

Uma vez que o servidor MCP e o cheat sheet estão prontos, repetir esse build em outro site é só trocar o endereço e os campos desejados no pedido — o resto do fluxo (map → extract → CSV, com fallback pra scrape) já está ensinado. É o tipo de trabalho que compensa automatizar de verdade — assunto que a Trilha 4 (Deploy) vai levar adiante.

Novo aqui? "Automatizar" aqui significa deixar essa mesma rotina rodar sozinha, sem você precisar copiar e colar o pedido de novo — por exemplo, gerar o CSV atualizado toda segunda de manhã. Este módulo te dá o build manual, sob demanda; a Trilha 4 ensina a colocar esse mesmo pedido numa agenda fixa, rodando num servidor, sem depender do seu laptop ligado. Pense nesse módulo como o protótipo que prova que o pedido funciona — só depois de validado é que vale a pena investir tempo em automatizá-lo de verdade.