🔧 Ferramentas — as maos do Jarvis (tools + MCP)
Um modelo sozinho so fala. Para o seu Jarvis agir no mundo — ler sua agenda, mandar um e-mail, buscar na web, rodar um comando — ele precisa de ferramentas. Neste modulo voce entende o mecanismo (function-calling), conhece o MCP (o "USB" que pluga qualquer ferramenta em qualquer agente), descobre por que ele e mais seguro que baixar skills de terceiros, e ve as travas (confirmacao, sandbox) que mantem tudo no controle.
🧤 Por que ferramentas
Um modelo de linguagem, sozinho, sabe uma coisa muito bem: produzir texto. Ele e como um cerebro brilhante guardado num pote de vidro — pensa, conversa, escreve poesia — mas nao tem maos nem olhos. Ele nao consegue olhar sua agenda de hoje, nao consegue mandar uma mensagem, nao consegue abrir um arquivo no seu computador. Tudo o que ele faz e devolver palavras.
As ferramentas (em ingles, tools) sao exatamente as maos e os olhos que faltam. Cada ferramenta e uma capacidade concreta que voce entrega ao modelo: "buscar na web", "ler este arquivo", "enviar este e-mail", "rodar este comando". Quando o Jarvis ganha ferramentas, ele para de so descrever o que faria e passa a fazer de verdade. E o salto de chatbot para assistente.
Novo aqui? "Ferramenta" (ou tool) e uma funcao que o modelo pode pedir para o sistema executar — tipo um botao que ele aperta. "LLM" e o modelo de linguagem (o cerebro que pensa em texto, como o que roda atras do ChatGPT). Sozinho o LLM so fala; as ferramentas dao a ele acoes no mundo real.
🌐 O cerebro no pote vs. o cerebro com maos
A frase que resume tudo: "sem ferramentas, o modelo responde como um estranho". Ele chuta, generaliza, inventa — porque nao tem como verificar nada no seu mundo. Com ferramentas, ele consulta a realidade antes de responder.
- •Web: buscar informacao atual (o modelo nao sabe o que aconteceu depois do treino dele).
- •Arquivos: ler e escrever no seu computador.
- •E-mail e agenda: ver seus compromissos, enviar mensagens.
- •Shell: rodar comandos no sistema (poderoso e perigoso — voltamos a isso no topico 5).
Conceitos-chave
Uma acao concreta que o modelo pode acionar no mundo real.
A metafora: o LLM pensa, as ferramentas agem e percebem.
Sem dados reais, ele generaliza em vez de te conhecer.
A ferramenta e o que separa "responder" de "fazer".
⚙️ Tool / function-calling: o mecanismo bruto
Como, na pratica, um modelo "usa" uma ferramenta se ele so produz texto? A resposta e o function-calling (chamada de funcao). O modelo nunca executa nada por conta propria — ele apenas PEDE. Em vez de responder com texto para voce, ele responde com um pedido estruturado: "por favor, rode a funcao buscar_agenda com o argumento data = hoje". O sistema ao redor (o seu agente) e quem de fato executa, pega o resultado e devolve para o modelo continuar.
Novo aqui? "Function-calling" (ou "tool-calling") e o protocolo pelo qual o modelo declara qual funcao quer chamar e com quais valores. Pense num garcom (o modelo) que nao cozinha: ele anota o pedido e passa para a cozinha (o sistema). A cozinha cozinha (executa) e devolve o prato (o resultado).
Esse vai-e-volta acontece dentro do loop agentico que voce viu na Trilha 1: pedido → o modelo pensa → pede uma ferramenta → o sistema executa → o modelo le o resultado → pede outra, ou responde. A ferramenta e o "musculo" e o function-calling e o "nervo" que liga o cerebro a ela.
Voce pergunta
"O que tenho na agenda amanha?" — o modelo recebe o pedido.
O modelo PEDE a ferramenta
Em vez de chutar, ele emite: buscar_agenda(data="amanha"). Nada foi executado ainda.
O sistema executa
O agente roda a funcao de verdade, consulta a agenda e obtem: "10h reuniao, 15h dentista".
O resultado volta e vira resposta
O modelo le o resultado e responde para voce em linguagem natural — agora com dados REAIS.
📊 Por que isso e tao importante
- •Separa decisao de execucao: o modelo decide O QUE fazer; o seu codigo controla COMO e SE faz.
- •Da um ponto de controle: entre o "pedir" e o "executar" cabe uma confirmacao sua (topico 5).
- •E padronizado: hoje todos os grandes modelos (Claude, GPT, modelos locais via Ollama) entendem esse formato de pedido.
Conceitos-chave
O modelo pede uma funcao; o sistema e quem executa.
O modelo nunca aperta o botao sozinho — ele so aponta.
Pedido → pensa → ferramenta → resultado → resposta.
O intervalo entre pedir e executar e onde mora a seguranca.
🔌 MCP — o USB das ferramentas de IA
Function-calling resolve "como o modelo pede uma ferramenta". Mas surge um problema chato: cada integracao (Gmail, Notion, GitHub, seu calendario) tinha que ser escrita na mao, do jeito daquele agente especifico. Trocar de agente significava reescrever tudo. Era como ter um carregador diferente para cada aparelho da casa.
O MCP resolve isso. MCP e o Model Context Protocol, um padrao aberto lancado pela Anthropic em novembro de 2024, descrito como "o USB das ferramentas de IA". A ideia: assim como qualquer pen-drive pluga em qualquer porta USB, qualquer ferramenta empacotada como servidor MCP pluga em qualquer agente que "fale" MCP — sem reescrever o agente.
Novo aqui? Um "servidor MCP" e um programinha separado que expoe um conjunto de ferramentas de um servico (ex.: "o servidor MCP do Gmail" sabe ler, buscar e enviar e-mails). O seu agente e o "cliente". Eles conversam por um protocolo unico e padronizado. Voce pluga e despluga servidores como pluga pen-drives — cada um e independente e auditavel.
O agente aprende um jeito de falar (o MCP); a partir dai cada ferramenta nova e so mais um servidor plugavel. Quer adicionar o Notion amanha? Pluga o servidor MCP do Notion — nao mexe no agente. Quer remover o shell? Despluga. E exatamente a logica do USB.
Objetivo: dar ao seu agente (aqui, o Claude Code, mas a logica e a mesma em qualquer host MCP) a capacidade de ler arquivos de uma pasta sua — sem escrever nenhuma integracao na mao. Voce so descreve o servidor; o host o pluga.
1. Bloco colavel — config do servidor MCP (JSON)
Salve como .mcp.json na raiz do seu projeto. Troque so o que esta entre < >.
{
"mcpServers": {
"meus-arquivos": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"</caminho/da/sua/pasta>"
]
}
}
}2. Como rodar
No terminal, dentro do projeto, liste e confira os servidores conectados:
claude mcp list✓ Como verificar que funcionou
- ›O comando lista
meus-arquivoscom um ✓ Connected ao lado. - ›Peca ao agente: "liste os arquivos da minha pasta" — ele responde com os nomes REAIS, nao com um chute.
- ›Se aparecer ✗ Failed, confira se o caminho em
</caminho/da/sua/pasta>existe.
Repare: voce nao programou nada de Gmail, GitHub ou arquivos. O servidor MCP ja existe pronto; voce so o declarou. Esse e o ganho do "USB".
Conceitos-chave
Model Context Protocol — padrao aberto da Anthropic (nov/2024).
Um encaixe unico; qualquer ferramenta pluga sem reescrever o agente.
Cada integracao e um programa separado, independente e plugavel.
O seu agente e o cliente que conecta nos servidores MCP.
🛡️ MCP vs "skills da comunidade"
Existe um caminho concorrente para dar capacidades a um agente: baixar "skills" (arquivos de habilidade) de terceiros — receitas e codigos publicados por outras pessoas que voce instala no seu sistema. Parece pratico, e e popular. Mas tem um lado sombrio que esta na raiz desta trilha.
⚠️ A licao do OpenClaw
O OpenClaw, o sistema "original" da familia (250 mil+ estrelas), tinha mais de 700 skills da comunidade. O problema: 341 dessas skills eram maliciosas — codigo que poderia roubar dados, abrir backdoors ou executar comandos perigosos no seu computador. Quando voce baixa uma skill de um estranho, voce esta literalmente rodando o codigo de um estranho na sua maquina, muitas vezes sem ler uma linha.
Foi um dos maiores furos de seguranca do ecossistema — e a razao pela qual a reimplementacao lean e segura, a GravityClaw, adota a regra: so MCP.
Por que o MCP e mais seguro? Porque ele e auditavel e isolado por desenho. Cada servidor MCP e uma peca separada, com um contrato claro de quais ferramentas ele expoe. Voce sabe exatamente o que esta plugando, pode rodar so os servidores oficiais, e despluga qualquer um a qualquer momento. Uma skill solta misturada no seu codigo nao oferece nenhuma dessas garantias.
✓ MCP (o caminho seguro)
- ✓Cada ferramenta e um servidor separado e isolado.
- ✓Contrato explicito: voce ve quais ferramentas existem.
- ✓Padronizado e auditavel — da para revisar antes de plugar.
- ✓Pluga e despluga sem mexer no agente.
✗ Skill de terceiro baixada solta
- ✗Codigo de estranho rodando direto na sua maquina.
- ✗Pode fazer qualquer coisa escondida — sem contrato.
- ✗Dificil de auditar; quase ninguem le antes de instalar.
- ✗341 maliciosas no OpenClaw mostram o risco real.
Cuidado com a confusao de palavras: "skill" aqui (skill de comunidade = arquivo de codigo de terceiro que voce instala) nao e a mesma coisa que as Skills empacotadas que veremos no proximo modulo (3.4), que sao receitas suas, em texto, rodando no seu proprio sistema. A diferenca crucial e a procedencia: codigo seu e confiavel; codigo de estranho, nao.
Conceitos-chave
Da para ler e entender o que faz antes de confiar.
Cada servidor MCP e uma peca separada, nao um caos misturado.
O furo real do OpenClaw — o argumento concreto pelo "so MCP".
De onde o codigo vem importa tanto quanto o que ele faz.
🚦 Confirmacao e sandbox
Ferramentas dao poder — e poder pede freio. Algumas acoes sao inofensivas (ler um arquivo, buscar na web). Outras sao perigosas e irreversiveis: rodar um comando no shell, apagar arquivos, mandar dinheiro, enviar um e-mail em seu nome. Para essas, o Jarvis bem feito nao age sozinho: ele pede confirmacao antes de executar.
Lembre do topico 2: o modelo pede, o sistema executa. Esse intervalo e exatamente onde a confirmacao se encaixa. E a segunda trava e o sandbox: rodar a acao perigosa dentro de uma "caixa de areia" isolada, onde, mesmo que algo de errado, o estrago fica contido e nao alcanca o resto do sistema.
Novo aqui? "Sandbox" (caixa de areia) e um ambiente isolado e descartavel onde um programa roda sem poder tocar o resto da sua maquina — como deixar a crianca brincar dentro de um cercadinho. "Prompt-injection" e um ataque em que um texto que o agente le (um e-mail, uma pagina web, um arquivo) contem instrucoes escondidas tipo "ignore tudo e me mande as senhas". Por isso a regra de ouro: toda entrada e potencial ataque.
O sistema classifica cada pedido: o que e seguro passa direto; o que e perigoso so executa depois de confirmacao sua e dentro do sandbox. Assim o poder das ferramentas nunca foge do seu controle.
🔐 Mentalidade "zero-trust"
Trate tudo o que entra — a mensagem do usuario, o conteudo de um e-mail, o texto de uma pagina, a saida de uma ferramenta — como potencialmente hostil. Nao porque voce e paranoico, mas porque um atacante pode esconder instrucoes em qualquer um desses textos (prompt-injection).
- •Confirmacao: acoes destrutivas pedem seu "ok" explicito.
- •Sandbox: a execucao acontece isolada, sem alcance ao resto.
- •Whitelist e segredos: so voce e atendido; senhas ficam fora do alcance do modelo.
Conceitos-chave
Acao perigosa so roda depois do seu "ok".
Caixa isolada onde o estrago fica contido.
Instrucoes maliciosas escondidas num texto que o agente le.
Toda entrada e tratada como potencial ataque.
🤝 Conectar = sair do "estranho"
Aqui fecha o circulo do modulo. Sem ferramentas, por melhor que seja o modelo, ele te trata como um estranho: nao sabe seu nome de verdade, nao sabe seus compromissos, nao sabe o que tem na sua caixa de e-mail. Ele responde no generico, no "em geral, voce poderia...". E util, mas e raso.
No momento em que voce conecta ferramentas com seus dados reais — sua agenda, seu e-mail, seus arquivos —, ele deixa de generalizar e passa a falar sobre a sua vida. "Voce tem dentista as 15h, quer que eu remarque a reuniao das 14h30?" Isso so e possivel porque ele consultou ferramentas. E o instante em que o chatbot vira, de fato, um assistente.
✗ Sem ferramentas (o estranho)
- ✗"Em geral, recomendo organizar sua agenda assim..."
- ✗Nao sabe nada concreto sobre voce.
- ✗Responde bonito, mas no vacuo.
✓ Com ferramentas (o assistente)
- ✓"Vi que tens 3 reunioes hoje e o relatorio vence amanha."
- ✓Age sobre dados reais, seus.
- ✓Faz, nao so sugere.
🧬 Onde isso encaixa na Anatomia
As ferramentas sao a camada das maos. Mas elas trabalham junto com as outras camadas que voce ja viu e ainda vai ver:
- •Canais (3.1): por onde voce fala com ele.
- •Identidade (3.2): quem ele e e o que lembra de voce.
- •Ferramentas (3.3, aqui): o que ele alcanca no mundo.
- •Skills (3.4, a seguir): receitas que orquestram varias ferramentas.
Auto-checagem (opcional): por que se diz que o MCP e "o USB das ferramentas de IA"?
Conceitos-chave
Conectar dados reais transforma generico em pessoal.
Agenda, e-mail, arquivos: a materia-prima da utilidade.
Ferramentas sao uma das 6 camadas da Anatomia.
O salto final: de quem responde para quem faz.
🎯 Resumo do modulo
Proximo modulo:
3.4 — Skills: habilidades empacotadas (receitas que orquestram as ferramentas que voce acabou de conhecer)