Uma única conexão MCP expõe um conjunto inteiro de ferramentas externas, e o agente decide qual chamar. O diagrama abaixo mostra o agente conectado a um server MCP que dá acesso a scraping, bancos e documentos — e o fluxo de pesquisa que nasce daí.
Diagrama ilustrativo — recriação conceitual da arquitetura MCP, não uma captura de tela real.
🔌 O que é MCP (Model Context Protocol)
MCP (Model Context Protocol) é um protocolo que deixa uma única conexão expor muitas ferramentas e ações. Depois que o agente e o server MCP se conectam, o agente conhece todas as ferramentas disponíveis e decide sozinho qual chamar, quando e com quais parâmetros. A analogia: é como o Gmail expor as ações "enviar", "rascunhar" e "buscar e-mails" — o agente descobre qual usar.
💡 A ideia central
Em vez de programar uma integração por ferramenta, você conecta um server MCP e ganha um conjunto inteiro de capacidades de uma vez. O agente passa a "ver" essas ferramentas e a orquestrá-las sem você dizer qual chamar.
- •Uma conexão: expõe várias ações de uma só vez.
- •Autonomia: o agente escolhe a ferramenta e os parâmetros.
- •Padrão: o mesmo protocolo serve para muitos serviços.
Padrão de conexão.
Um server, várias ferramentas.
Escolhe qual chamar.
Gmail: enviar/rascunhar/ler.
🗂️ Onde encontrar MCP servers
Servers MCP ficam em diretórios dedicados (como o mcp.so) e também aparecem na busca do GitHub por "MCP server" mais o nome do serviço. Saber onde procurar — e em que categoria a sua necessidade se encaixa — acelera a escolha da ferramenta certa para a tarefa.
Raspar e ler páginas da web. Exemplo usado nesta trilha: Firecrawl.
Ler e escrever dados. Exemplos: Postgres, Supabase.
Acessar arquivos e notas. Exemplos: Google Drive, Notion.
Enviar mensagens e e-mails. Exemplos: Slack, Gmail.
🎯 Dica prática
Antes de instalar, pense na categoria: "preciso de scraping, de banco, de documento ou de comunicação?". Isso reduz a busca e evita instalar servers que você nem vai usar (e que consomem contexto).
mcp.so e similares.
Buscar "MCP server" + serviço.
Scraping/bancos/docs/comm.
Só o que a tarefa pede.
📦 Instalar um MCP server
Para instalar, você dá ao agente o comando de instalação da documentação do provedor; ele gera o arquivo .mcp.json com a entrada do server e um placeholder de chave. Depois, você se cadastra no provedor, obtém a API key e a insere manualmente no arquivo de configuração — nunca colando no chat.
Passo a passo da instalação
Copiar o comando da documentação
Na doc do provedor (ex.: Firecrawl → Integrations → MCP → seção do assistente de código), copie o comando de instalação.
Deixar o agente gerar o .mcp.json
Peça para instalar usando aquele comando; ele cria o .mcp.json com a config do server e o placeholder da chave.
Inserir a chave manualmente
Cadastre-se no provedor, copie sua API key e cole você mesmo no arquivo de config — fora do chat.
⚠️ Atenção: a chave de API
- ✗Nunca cole a chave no chat nem deixe o agente inseri-la.
- ✗Insira manualmente no arquivo de configuração — é mais seguro.
- ✗Trate a chave como acesso ao cartão: vazou, qualquer um gasta.
Da doc do provedor.
Gerado pelo agente.
Nunca no chat.
Cadastro + API key.
🩺 Verificar e diagnosticar
Depois de instalar, verifique com o comando /mcp: ele lista os servers instalados e o status de cada um. Se um server recém-instalado não aparece, a causa mais comum não é falha de instalação — é só falta de reiniciar o assistente para registrar os novos componentes.
✓ Faça
- ✓Rode
/mcppara ver os servers e o status. - ✓Reinicie o assistente se o server não aparecer.
- ✓Confirme a conexão antes de começar a usar a ferramenta.
✗ Não faça
- ✗Achar que a instalação falhou sem antes reiniciar.
- ✗Reinstalar do zero por impaciência.
- ✗Usar a ferramenta sem confirmar que o status está "conectado".
🎯 Dica prática
"Não apareceu? Reinicie." Esse reflexo resolve a maioria dos casos de server invisível e poupa horas de diagnóstico desnecessário.
Lista servers + status.
Registra novos servers.
Conectado ou não.
Faltou reiniciar.
🔎 Workflow de pesquisa com Firecrawl
Com o MCP no lugar, dá para construir um workflow de pesquisa de ponta a ponta: você dá um tema, o agente pesquisa a web com Firecrawl, sintetiza os achados e gera um documento estruturado. Tudo reaproveitando o framework WAT e um CLAUDE.md WAT como configuração-mestra lida a cada sessão.
Plan → Build → Run
Plan — descrever o workflow
Em Plan Mode, descreva: dar um tema, pesquisar a web, achar info relevante e atual, compilar num brief estruturado e gerar um documento na pasta temporária via Firecrawl. Responda às perguntas (formato de saída, nº de fontes).
Build — gerar workflows + tools
O agente gera o .env, o .mcp.json do Firecrawl, a ferramenta de conversão markdown → documento e o workflow de pesquisa.
Run — disparar com um tema
Limpe o contexto e dispare com um tema concreto. O agente lê o workflow, roda as buscas no Firecrawl, sintetiza e converte em documento.
🎯 O que o workflow especifica
Um bom workflow de pesquisa declara gatilhos, entradas, passos, um alvo de fontes (ex.: 3-5 buscas direcionadas), tratamento de erro e critérios para avaliar cada fonte — assim a saída é consistente e confiável.
A entrada do workflow.
Pesquisa a web.
Compila um brief.
Alvo de buscas.
📄 Pipeline de saída
O pipeline de saída separa conteúdo de formato: o agente produz primeiro um markdown e depois o converte para um arquivo de documento por meio de uma ferramenta gerada de conversão. Isso deixa a saída flexível — o mesmo conteúdo pode virar formatos diferentes — e fácil de auditar.
tema → busca Firecrawl → síntese → brief.md (conteúdo, markdown) → ferramenta de conversão → brief.docx (formato, documento)
⚠️ Atenção: a sincronia dos dois arquivos
- ✗Atualizar o markdown nem sempre atualiza o documento final.
- ✗Ao pedir uma mudança, peça explicitamente para atualizar os dois.
- ✗Não confie só na aparência do markdown — abra o documento gerado.
🎯 Dica prática
Quando mudar a formatação (ex.: trocar a seção de fontes de tabela para lista), peça para propagar a mudança ao markdown e ao documento. Caso contrário, você corrige um e o outro fica desatualizado.
O conteúdo primeiro.
Ferramenta gerada.
O formato final.
Atualize os dois.
♻️ Iteração & auto-cura
O primeiro run raramente sai perfeito — e tudo bem. A qualidade vem do loop de iteração: você dá feedback específico ("gostei da estrutura, mas reformate as fontes como lista") e, se algo quebra, pede para a própria IA se consertar (auto-cura). Quanto mais específico o feedback, melhor o resultado.
✓ Feedback que funciona
- ✓"Reformate a seção de fontes de tabela para lista."
- ✓"O tom está formal demais; deixe mais direto."
- ✓"Quebrou? Olhe o erro e se conserte."
✗ Feedback que trava
- ✗"Está ruim." (sem dizer o que nem onde)
- ✗"Refaça tudo." (joga fora o que já estava bom)
- ✗Desistir no primeiro erro em vez de pedir o conserto.
🔁 O loop de auto-cura
Se o workflow falha, copie o erro e devolva à IA pedindo o conserto. Lembre de pedir que a correção entre no workflow e na ferramenta, não só no resultado — assim a próxima execução já nasce certa.
Primeiro run não é o final.
Diga o quê e onde.
Pedir para se consertar.
Correção no workflow.
🧠 Checagem rápida
Onde você deve inserir a API key de um MCP server recém-instalado?
📌 Resumo do Módulo
Próximo Módulo:
2.3 — Skills, Geração de Artefatos & Tokens