Conteúdo detalhado
❓ Skill, CLI, API ou só MCP?
Antes de conectar qualquer ferramenta ao seu OS, faça uma auditoria: ela te dá uma skill, uma CLI, uma API ou só um MCP? A resposta decide o caminho — e às vezes você usa uma combinação dos quatro.
🌱 Novo aqui?
Os quatro conectores, em uma frase cada: uma API é a porta de dados de um serviço (a "entrada de serviço" do prédio). Uma CLI (command-line interface) é um programa de terminal que conversa com esse serviço — um controle remoto enxuto. Um MCP (Model Context Protocol) é um adaptador de tomada que pluga a IA numa ferramenta externa. E uma skill é a receita que usa esses fios. Saber qual existe pra cada ferramenta é o ponto de partida.
Como ler: há quatro fios possíveis entre o OS e a mesma ferramenta. A pergunta deste módulo é qual deles escolher — e a ferramenta nem sempre oferece todos.
Por que aprender
Porque escolher o conector errado custa caro — em manutenção e em contexto. Fazer a pergunta antes filtra o esforço: se há uma skill pronta, talvez você não precise construir nada; se há API e o trabalho é de linha de comando, talvez valha uma CLI sua.
Conceitos-chave
📉 MCP fica menos relevante com o tempo
Um padrão que o autor observa: com o tempo, o MCP tende a ficar menos relevante. Ele continua útil num caso específico — quando a ferramenta dá MCP mas não dá API. Aí você usa o que tem. Mas, havendo API, quase sempre uma skill ou uma CLI própria serve melhor.
💡 A pergunta de auditoria
"Esta ferramenta me dá skill, CLI e API — ou só MCP?" Se dá API e o trabalho é muito de linha de comando, você cria a sua CLI. Se só dá MCP, instale o MCP sem culpa: é o melhor disponível ali.
✓ Quando o MCP faz sentido
- ✓A ferramenta só oferece MCP, sem API.
- ✓Você precisa de algo rápido, sem manter código.
- ✓É um uso pontual, não o coração do OS.
✗ MCP por reflexo
- ✗Instalar MCP quando há API disponível.
- ✗Acumular MCPs "por garantia" no OS.
- ✗Ignorar a CLI própria, mais enxuta e controlável.
Por que aprender
Porque te tira do piloto automático de "instalar o MCP da moda". Ao tratar o MCP como exceção (só-MCP, sem API), você prefere conexões mais enxutas e controláveis — e o seu OS acumula menos peças para manter.
Conceitos-chave
🛠️ Criar sua própria CLI a partir de uma API
Aqui está o superpoder desta camada: você pode envolver qualquer API numa CLI sua. Se a ferramenta dá uma API e você faz muitas ações de linha de comando, é só pedir ao Claude Code: "transforme esta API numa CLI customizada, e estas são as funções que me importam".
Recriação ilustrativa — o que você ganha
# antes: chamada de API crua, verbosa curl -X GET https://api.servico.com/v1/registros?limit=50 \ -H "Authorization: Bearer $TOKEN" # depois: sua CLI, enxuta meuservico listar --limite 50
💡 A sacada
Você não envolve a API inteira — só as funções que te importam. A CLI vira a sua "criação de contexto de ferramenta": um vocabulário enxuto e seu, que o Claude Code usa de forma previsível, sem ter que lembrar de endpoints e cabeçalhos.
Por que aprender
Porque destrava qualquer ferramenta com API. Em vez de depender do MCP de terceiro ou de chamadas cruas, você desenha o controle remoto do jeito do seu OS — só com os botões que usa. E é a base do hack de segurança do próximo tópico.
Conceitos-chave
🔒 O hack de segurança: a CLI somente leitura
Este é o tópico que muda a forma como você conecta o OS a dados que importam. Quando você cria a sua CLI a partir da API, pode intencionalmente tirar todo o acesso de escrita. A CLI só lê informação, nunca grava. Esse "truque interessante" é uma das maiores reduções de risco do curso inteiro.
🌱 Novo aqui?
Em APIs, ler dados é um GET; gravar/alterar é um POST/PUT/DELETE. Uma CLI read-only (somente leitura) só implementa os GET — os comandos de escrita simplesmente não existem nela. Não é uma regra "mole" pedindo para a IA não escrever: é a ausência física do botão.
Como ler: a leitura (em ciano) atravessa a CLI e chega ao banco. A escrita (em vermelho) bate num X antes da CLI — porque o comando de escrita simplesmente não foi implementado. É um tripwire físico, não uma promessa.
✓ CLI read-only
- ✓Só lê — nunca sobrescreve dados.
- ✓Um POST acidental não tem como acontecer.
- ✓Você confia mesmo fundo na janela de contexto.
✗ API/skill com escrita
- ✗O Claude pode rodar um POST que sobrescreve.
- ✗Risco cresce conforme você se aprofunda na sessão.
- ✗Um deslize "explode" o banco de dados.
Por que aprender
Porque é a diferença entre confiar e torcer. Se você apontar o Claude Code direto para a API ou uma skill com escrita, ele pode — dependendo de quão fundo está no contexto — disparar um endpoint que sobrescreve dados. A CLI read-only remove essa possibilidade na raiz: o tripwire que mantém o sistema seguro o suficiente para você usar todo dia.
Conceitos-chave
🧰 Seja intencional: toda infra vira manutenção
Poder envolver toda API numa CLI não significa que você deva. Seja muito intencional com a infra que adiciona — porque, no fim do dia, você vai ter que mantê-la. Cada CLI, cada conexão, é uma peça nova que pode quebrar e pedir atenção.
Por que aprender — o ciclo de vida de uma peça de infra
Você adiciona
Uma CLI nova resolve uma dor de hoje. Parece grátis — é só pedir ao Claude Code.
A ferramenta muda
A API que ela envolve atualiza, um campo some, um token expira. A peça começa a falhar.
Vira manutenção
Você quebra a cabeça mantendo algo que talvez nem fosse essencial. A dívida cobra juros.
🔎 A pergunta antes de construir
"Essa CLI me dá tanto valor que justifica mantê-la?" Se uma skill pronta já faz o trabalho — como a Appify skill faz scraping —, o autor prefere não quebrar as costas mantendo uma CLI própria. Menos peças, menos juros de dívida.
Por que aprender
Porque a infra é sedutora e silenciosamente cara. Cada fio que você puxa pra fora é um compromisso de manutenção. Ser intencional mantém o OS leve, confiável e fácil de auditar — o oposto de uma teia de conexões que você não lembra por que criou.
Conceitos-chave
🧩 Exemplos reais: Supabase, Obsidian, Appify
Como isso aparece nos OS reais do autor? Três exemplos mostram quando criar a sua infra e quando uma skill de terceiro já basta — a decisão central deste módulo.
No Health OS: criar bancos, editar tabelas, tudo sem fricção. CLI faz sentido porque o uso é constante e de linha de comando.
O "segundo cérebro": guardar metas e notas de saúde para o OS consultar quando precisa. CLI própria conecta tudo facilmente.
Scraping de fontes (YouTube, LinkedIn). Aqui o autor usa a skill pronta — não precisa de CLI própria; ela já faz o trabalho.
💡 O padrão
Supabase e Obsidian viram CLI própria porque o uso é intenso, contínuo e de linha de comando. Appify fica como skill pronta porque ela já resolve — criar uma "Appify CLI" só somaria manutenção. Às vezes você combina os três tipos no mesmo OS.
Por que aprender
Porque exemplos concretos calibram o seu julgamento. Você passa a perguntar, diante de cada ferramenta: "isso é uso intenso de linha de comando (CLI própria) ou já existe uma skill que faz (use-a)?". Esse é o filtro que mantém a camada de Ferramentas enxuta.
Conceitos-chave
📝 Copy-run: transforme esta API numa CLI read-only
Hora de juntar tudo: o tópico 3 (CLI a partir de API) com o tópico 4 (o hack read-only). Pegue uma ferramenta sua com API — um banco, um CRM, um Supabase — e peça ao Claude Code para envolvê-la numa CLI que fisicamente não escreve. Cole o prompt abaixo.
Copie e rode no Claude Code
Objetivo: gerar uma CLI somente leitura sobre uma API, com as funções que você lista — sem nenhum caminho de escrita.
Cole no Claude Code (troque o que está entre < >):
Transforme a API de <nome-da-ferramenta> numa CLI customizada chamada <nome-da-cli>, SOMENTE LEITURA. Regra inegociável de segurança: - implemente APENAS endpoints de leitura (GET / list / read); - NÃO gere nenhum comando que faça POST, PUT, PATCH ou DELETE; - se eu pedir um comando de escrita, recuse e explique que esta CLI é read-only por desenho. Funções que me importam: - <listar X com filtro Y> - <buscar um registro por id> - <exportar leitura para um arquivo> Use o token de <onde está o segredo, ex.: variável de ambiente> — nunca escreva o segredo no código. Antes de criar os arquivos, liste os comandos que vai gerar e confirme que NENHUM escreve. Espere meu OK.
Como verificar: rode <nome-da-cli> --help e confirme que só aparecem comandos de leitura. Depois peça explicitamente uma escrita ("apague o registro 5") — a CLI deve recusar porque o comando não existe. Esse é o tripwire físico do tópico 4 na prática.
⚠️ Não relaxe o read-only
A tentação vai aparecer: "só esse um comandinho de escrita". No instante em que você adiciona escrita, o tripwire some e o risco do POST acidental volta. Se precisar mesmo escrever, faça por um caminho separado e explícito — nunca afrouxando a CLI read-only.
Por que aprender
Porque é o exercício que materializa a segurança. Ao rodar este prompt você sai com uma CLI que conecta o OS aos seus dados sem o risco de destruí-los — o padrão de produção que volta em todos os domínios da Trilha 5.
Conceitos-chave
🚫 Quando NÃO criar infra
Fechamos a camada com a decisão mais madura: saber parar. Reconhecer quando NÃO criar infra é tão valioso quanto saber construí-la. Se uma skill pronta já entrega o resultado, criar a sua versão só adiciona dívida.
✓ Construa quando
- ✓O uso é intenso e de linha de comando.
- ✓Você precisa do hack read-only para se proteger.
- ✓Nenhuma skill/MCP pronto cobre o caso.
✗ Não construa quando
- ✗Uma skill pronta (ex.: Appify) já faz o trabalho.
- ✗É uso pontual que não justifica manutenção.
- ✗Você só quer construir "por orgulho" de ter feito.
🔎 A regra do autor
"Estou mais do que feliz em usar a Appify skill. Não tenho necessidade de fazer a minha CLI da Appify — a skill faz o trabalho melhor do que eu precisava." Não quebrar as costas mantendo infra que outro já resolveu é uma decisão de engenharia, não de preguiça.
Por que aprender
Porque a maturidade da camada de Ferramentas é saber escolher entre construir e reusar. Cada peça extra é dívida que cobra juros. Parar na hora certa mantém o OS leve — e te deixa pronto para a última camada de ação: os Agentes.
Conceitos-chave
✅ Resumo do módulo
Próximo módulo:
3.3 — Agentes: papéis com julgamento 🤖