Detailed content
❓ Skill, CLI, API, or just MCP?
Before connecting any tool to your OS, audit it: does it give you a skill, one CLI, one API or just one MCP? The answer determines the path—and sometimes you use a combination of all four.
🌱 New here?
The four connectors, one sentence each: a API is a service’s data doorway (the building’s "service entrance"). A CLI (command-line interface) is a terminal program that communicates with this service—a compact remote control. A MCP (Model Context Protocol) is a power adapter that plugs AI into an external tool. And an skill is the recipe that uses those wires. Knowing which one exists for each tool is the starting point.
How to read: there are four possible paths between the OS and the same tool. This module asks which one to choose—and the tool doesn't always offer all of them.
Why learn
Because choosing the wrong connector is costly—in maintenance and context. Asking the question first filters the effort: if there’s a ready-made skill, you may not need to build anything; if there’s an API and the work is command-line based, building your own CLI may be worthwhile.
Key concepts
📉 MCP becomes less relevant over time
A pattern the author observes: over time, the MCP tends to become less relevant. It remains useful in one specific case—when the tool provides MCP but no provides an API. Then you use what you have. But when there is an API, a skill or a custom CLI is almost always a better fit.
💡 The audit question
"Does this tool give me a skill, CLI, and API — or only MCP?" If an API is available and the work is mostly command-line based, create your own CLI. If only MCP is available, install the MCP without guilt: it's the best available there.
✓ When MCP makes sense
- ✓The tool only offers MCP, with no API.
- ✓You need something quick, without maintaining code.
- ✓It’s an occasional use, not the heart of the OS.
✗ MCP by reflex
- ✗Install MCP when an API is available.
- ✗Accumulating MCPs "just in case" in the OS.
- ✗Ignoring the leaner, more controllable custom CLI.
Why learn
Because it gets you off autopilot when it comes to “installing the trendy MCP.” By treating MCP as an exception (MCP-only, no API), you favor leaner, more controllable connections—and your OS has fewer components to maintain.
Key concepts
🛠️ Build Your Own CLI from an API
Here’s the superpower of this layer: you can wrap any API in your own CLI. If the tool provides an API and you perform many command-line actions, just ask Claude Code: "turn this API into a custom CLI, and these are the functions I care about".
Illustrative recreation — what you get
# 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
💡 The key insight
You don’t involve the entire API — only the functions that matter to you. The CLI becomes your “tool context creation”: a concise vocabulary of your own that Claude Code uses predictably, without having to remember endpoints and headers.
Why learn
Because it unlocks any tool with an API. Instead of depending on a third-party MCP or raw calls, you design the remote control to fit your OS—with only the buttons you use. And it’s the foundation for the security hack in the next topic.
Key concepts
🔒 The security hack: the read-only CLI
This is the topic that changes how you connect the OS to data that matters. When you create your CLI from the API, you can intentionally remove all write access. The CLI only reads information; it never writes anything. This “interesting trick” is one of the biggest risk reductions in the entire course.
🌱 New here?
In APIs, reading data is a GET; recording/changing is a POST/PUT/DELETE. A CLI read-only (read-only) only implements GETs—the write commands simply don’t exist in it. It’s not a “soft” rule asking the AI not to write: it’s the physical absence of the button.
How to read: the read path (in cyan) goes through the CLI and reaches the database. The write path (in red) hits an X before the CLI—because the write command simply hasn’t been implemented. It’s a tripwire physical, not a promise.
✓ Read-only CLI
- ✓Read-only — never overwrites data.
- ✓An accidental POST can't happen.
- ✓You trust the context window deeply.
✗ API/skill with write access
- ✗Claude can run a POST that overwrites.
- ✗Risk grows as you go deeper into the session.
- ✗One slip-up "blows up" the database.
Why learn
Because it’s the difference between trusting and hoping. If you point Claude Code directly at the API or at a skill with write access, it might—depending on how deeply it’s embedded in the context—trigger an endpoint that overwrites data. The read-only CLI removes that possibility at the root: the tripwire that keeps the system safe enough for daily use.
Key concepts
🧰 Be intentional: all infrastructure becomes maintenance
Being able to wrap every API in a CLI doesn’t mean you should. Be very intentional about the infrastructure you add—because, at the end of the day, you'll have to maintain it. Every CLI, every connection, is a new component that can break and need attention.
Why learn — the lifecycle of a piece of infrastructure
You add
A new CLI solves a pain point today. It seems free—just ask Claude Code.
The tool changes
The API it relies on gets updated, a field disappears, a token expires. The component starts failing.
Becomes maintenance
You struggle to maintain something that might not even have been essential. The debt accrues interest.
🔎 The question before you build
"Does this CLI provide enough value to justify maintaining it?" If a ready-made skill already does the job — like the Appify skill handles scraping — the author would rather not break their back maintaining a custom CLI. Fewer parts, less technical debt.
Why learn
Because infrastructure is seductive and quietly expensive. Every wire you pull outward is a maintenance commitment. Being intentional keeps the OS lightweight, reliable, and easy to audit—the opposite of a web of connections you don’t remember creating.
Key concepts
🧩 Real examples: Supabase, Obsidian, Appify
How does this show up in the author's real OSes? Three examples show when to build your own infrastructure and when a third-party skill is enough — the central decision in this module.
In Health OS: create databases, edit tables, all frictionlessly. CLI makes sense because usage is constant and command-line based.
The “second brain”: storing goals and health notes for the OS to consult when needed. Its own CLI connects everything easily.
Source scraping (YouTube, LinkedIn). Here the author uses the ready-made skill—you don’t need your own CLI; it already does the job.
💡 The pattern
Supabase and Obsidian become Custom CLI because usage is intensive, continuous, and command-line based. Appify remains as ready-made skill because it already does the job — creating an "Appify CLI" would only add maintenance. Sometimes you combine all three types in the same OS.
Why learn
Because concrete examples calibrate your judgment. You start asking, for each tool: “Is this heavy command-line use (your own CLI), or is there already a skill that does it (use that)?” That’s the filter that keeps the Tools layer lean.
Key concepts
📝 Copy-run: turn this API into a read-only CLI
Time to put it all together: topic 3 (CLI from API) with topic 4 (the read-only hack). Pick one of your tools with an API — a database, a CRM, Supabase — and ask Claude Code to wrap it in a CLI that does not physically write. Paste the prompt below.
Copy and run in Claude Code
Objective: generate a read-only CLI for an API, with the functions you list — with no write path.
Paste into Claude Code (replace what’s between < >):
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.
How to verify: run <name-of-the-cli> --help and confirm that only read commands appear. Then explicitly request a write (“delete record 5”)—the CLI should refuse because the command doesn't exist. That's the topic 4's physical tripwire in practice.
⚠️ Don't relax read-only
The temptation will come up: "just this one little write command." The moment you add write access, the tripwire disappears and the risk of an accidental POST returns. If you really need to write, use a separate, explicit path—never loosen the read-only CLI.
Why learn
Because it’s the exercise that puts security into practice. Running this prompt gives you a CLI that connects the OS to your data without the risk of destroying it—the production pattern that comes back in every domain in Track 5.
Key concepts
🚫 When NOT to Create Infrastructure
We close out the layer with the most mature decision: knowing stop. Recognizing when NOT to create infrastructure is just as valuable as knowing how to build it. If an existing skill already delivers the result, creating your own version only adds debt.
✓ Build when
- ✓Use is intensive and command-line based.
- ✓You need the read-only hack to protect yourself.
- ✓No ready-made skill/MCP covers the case.
✗ Don’t build when
- ✗A ready-made skill (e.g., Appify) already does the job.
- ✗It’s occasional use that doesn’t justify maintenance.
- ✗You only want to build it "for the pride of having made it."
🔎 The author's rule
"I’m more than happy to use the Appify skill. I don’t need to build my own Appify CLI — the skill does the job better than I needed." Not breaking your back maintaining infrastructure someone else has already solved is an engineering decision, not laziness.
Why learn
Because maturity in the Tools layer means knowing when to build and when to reuse. Every extra piece is debt that compounds. Stopping at the right time keeps the OS lightweight—and gets you ready for the final action layer: Agents.
Key concepts
✅ Module summary
Next module:
3.3 — Agents: roles with judgment 🤖