Contenido detallado
❓ ¿Skill, CLI, API o solo MCP?
Antes de conectar cualquier herramienta a tu OS, haz una auditoría: ¿te da una skill, una CLI, una API o solo un MCP? La respuesta decide el camino, y a veces usas una combinación de los cuatro.
🌱 ¿Nuevo aquí?
Los cuatro conectores, en una frase cada uno: una API es la puerta de datos de un servicio (la "entrada de servicio" del edificio). Una CLI (interfaz de línea de comandos) es un programa de terminal que se comunica con ese servicio —un control remoto sencillo. Un MCP (Model Context Protocol) es un adaptador que conecta la IA a una herramienta externa. Y una skill es la receta que usa esos cables. Saber cuál existe para cada herramienta es el punto de partida.
Cómo leer: hay cuatro vías posibles entre el OS y la misma herramienta. La pregunta de este módulo es cuál elegir, y la herramienta no siempre ofrece todas.
Por qué aprender
Porque elegir el conector equivocado cuesta caro, en mantenimiento y en contexto. Hacer la pregunta antes filtra el esfuerzo: si ya hay una skill lista, quizá no necesites construir nada; si hay una API y el trabajo es de línea de comandos, quizá valga la pena crear tu propia CLI.
Conceptos clave
📉 MCP pierde relevancia con el tiempo
Un patrón que observa el autor: con el tiempo, el MCP tiende a perder relevancia. Sigue siendo útil en un caso específico: cuando la herramienta ofrece MCP, pero no proporciona API. Entonces usas lo que tienes. Pero, si hay una API, casi siempre una skill o una CLI propia funciona mejor.
💡 La pregunta de auditoría
"¿Esta herramienta me ofrece skill, CLI y API, o solo ¿MCP?" Si hay una API y el trabajo se hace mucho desde la línea de comandos, crea tu propia CLI. Si solo hay MCP, instala el MCP sin culpa: es lo mejor disponible ahí.
✓ Cuándo tiene sentido el MCP
- ✓La herramienta solo ofrece MCP, sin API.
- ✓Necesitas algo rápido, sin mantener código.
- ✓Es un uso puntual, no el corazón del OS.
✗ MCP por reflejo
- ✗Instalar MCP cuando hay una API disponible.
- ✗Acumular MCPs "por si acaso" en el OS.
- ✗Ignorar la CLI propia, más ligera y controlable.
Por qué aprender
Porque te saca del piloto automático de "instalar el MCP de moda". Al tratar el MCP como una excepción (solo MCP, sin API), prefieres conexiones más ligeras y controlables, y tu OS acumula menos piezas que mantener.
Conceptos clave
🛠️ Crear tu propia CLI a partir de una API
Este es el superpoder de esta capa: puedes envolver cualquier API en una CLI propia. Si la herramienta ofrece una API y haces muchas acciones desde la línea de comandos, solo tienes que pedirle a Claude Code: "convierte esta API en una CLI personalizada; estas son las funciones que me importan".
Recreación ilustrativa — lo que obtienes
# 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
💡 La idea clave
No involucras toda la API, solo las funciones que te importan. La CLI se convierte en tu «creación de contexto de herramientas»: un vocabulario conciso y propio que Claude Code usa de forma predecible, sin tener que recordar endpoints y encabezados.
Por qué aprender
Porque desbloquea cualquier herramienta con API. En lugar de depender del MCP de terceros o de llamadas directas, diseñas el control remoto a la medida de tu OS, solo con los botones que usas. Y es la base del truco de seguridad del siguiente tema.
Conceptos clave
🔒 El truco de seguridad: la CLI de solo lectura
Este es el tema que cambia la forma en que conectas el OS con datos importantes. Cuando creas tu CLI a partir de la API, puedes quitar intencionalmente todo el acceso de escritura. La CLI solo lee información, nunca escribe. Este «truco interesante» es una de las mayores reducciones de riesgo de todo el curso.
🌱 ¿Nuevo aquí?
En las API, leer datos es un GET; guardar/modificar es un POST/PUT/DELETE. Una CLI read-only (solo lectura) solo implementa los GET; los comandos de escritura simplemente no existen en ella. No es una regla «blanda» que le pide a la IA que no escriba: es la ausencia física del botón.
Cómo leer: la lectura (en cian) atraviesa la CLI y llega a la base de datos. La escritura (en rojo) choca con una X antes de la CLI, porque el comando de escritura simplemente no se implementó. Es un tripwire físico, no una promesa.
✓ CLI de solo lectura
- ✓Solo lee; nunca sobrescribe datos.
- ✓No hay forma de que ocurra una PUBLICACIÓN accidental.
- ✓Confías profundamente en la ventana de contexto.
✗ API/skill con escritura
- ✗Claude puede ejecutar un POST que sobrescribe.
- ✗El riesgo crece a medida que profundizas en la sesión.
- ✗Un desliz «hace explotar» la base de datos.
Por qué aprender
Porque es la diferencia entre confiar y cruzar los dedos. Si apuntas Claude Code directamente a la API o a una skill con permisos de escritura, puede, según la profundidad del contexto, activar un endpoint que sobrescribe datos. La CLI de solo lectura elimina esa posibilidad desde la raíz: el tripwire que mantiene el sistema lo bastante seguro para que lo uses a diario.
Conceptos clave
🧰 Sé intencional: toda infraestructura se convierte en mantenimiento
Poder envolver toda API en una CLI no significa que tú deba. Sé muy intencional con la infraestructura que añades, porque, al final del día, tendrás que mantenerla. Cada CLI, cada conexión, es una pieza nueva que puede fallar y requerir atención.
Por qué aprender — el ciclo de vida de una pieza de infraestructura
Tú agregas
Una CLI nueva resuelve un problema de hoy. Parece gratis: solo tienes que pedírselo a Claude Code.
La herramienta cambia
La API que la rodea se actualiza, desaparece un campo, vence un token. La pieza empieza a fallar.
Se convierte en mantenimiento
Te rompes la cabeza manteniendo algo que quizá ni siquiera era esencial. La deuda cobra intereses.
🔎 La pregunta antes de construir
"¿Esta CLI me aporta tanto valor como para justificar mantenerla?" Si una skill lista ya hace el trabajo —como la skill Appify, que hace scraping—, el autor prefiere no matarse manteniendo una CLI propia. Menos piezas, menos intereses de deuda.
Por qué aprender
Porque la infraestructura es seductora y silenciosamente costosa. Cada cable que sacas hacia afuera implica un compromiso de mantenimiento. Actuar con intención mantiene el OS ligero, confiable y fácil de auditar, lo opuesto a una red de conexiones cuyo motivo ya no recuerdas.
Conceptos clave
🧩 Ejemplos reales: Supabase, Obsidian, Appify
¿Cómo aparece esto en los OS reales del autor? Tres ejemplos muestran cuándo crear tu propia infraestructura y cuándo basta con una skill de terceros: la decisión central de este módulo.
En Health OS: crear bases de datos, editar tablas, todo sin fricción. La CLI tiene sentido porque el uso es constante y desde la línea de comandos.
El «segundo cerebro»: guardar metas y notas de salud para que el OS las consulte cuando las necesite. Una CLI propia conecta todo fácilmente.
Scraping de fuentes (YouTube, LinkedIn). Aquí el autor usa la skill lista: no necesita una CLI propia; la skill ya hace el trabajo.
💡 El patrón
Supabase y Obsidian se convierten en CLI propia porque el uso es intenso, continuo y desde la línea de comandos. Appify queda como skill lista porque ya lo resuelve — crear una "Appify CLI" solo sumaría mantenimiento. A veces combinas los tres tipos en el mismo OS.
Por qué aprender
Porque los ejemplos concretos calibran tu criterio. Empiezas a preguntarte, ante cada herramienta: "¿esto requiere un uso intensivo de la línea de comandos (CLI propia) o ya existe una skill que lo hace (úsala)?". Ese es el filtro que mantiene compacta la capa de Herramientas.
Conceptos clave
📝 Copy-run: convierte esta API en una CLI de solo lectura
Hora de unirlo todo: el tema 3 (CLI a partir de API) con el tema 4 (el hack de solo lectura). Toma una herramienta tuya con API —una base de datos, un CRM, un Supabase— y pídele a Claude Code que la envuelva en una CLI que físicamente no escribe. Pega el prompt de abajo.
Copia y ejecuta en Claude Code
Objetivo: generar una CLI de solo lectura sobre una API, con las funciones que enumeras, sin ninguna opción de escritura.
Pega en Claude Code (cambia lo 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.
Cómo verificar: ejecuta <nombre-de-la-cli> --help y confirma que solo aparecen comandos de lectura. Después pide explícitamente una escritura («borra el registro 5»): la CLI debería rechazarla porque el comando no existe. Este es el tripwire físico del tema 4 en la práctica.
⚠️ No relajes el read-only
La tentación aparecerá: "solo este comandito de escritura". En el instante en que agregas escritura, desaparece el tripwire y vuelve el riesgo de un POST accidental. Si realmente necesitas escribir, hazlo por una vía separada y explícita — nunca relajes la CLI de solo lectura.
Por qué aprender
Porque es el ejercicio que materializa la seguridad. Al ejecutar este prompt, terminas con una CLI que conecta el OS con tus datos sin el riesgo de destruirlos: el estándar de producción que vuelve a aparecer en todos los dominios de Trilha 5.
Conceptos clave
🚫 Cuándo NO crear infraestructura
Cerramos la capa con la decisión más madura: saber detenerse. Reconocer cuándo NO crear infraestructura es tan valioso como saber construirla. Si una skill existente ya da el resultado, crear tu propia versión solo añade deuda.
✓ Constrúyela cuando
- ✓El uso es intensivo y desde la línea de comandos.
- ✓Necesitas el hack de solo lectura para protegerte.
- ✓Ninguna habilidad/MCP listo cubre el caso.
✗ No construyas cuando
- ✗Una skill lista (p. ej., Appify) ya hace el trabajo.
- ✗Es un uso puntual que no justifica el mantenimiento.
- ✗Solo quieres construirlo "por orgullo" de haberlo hecho.
🔎 La regla del autor
"Estoy más que feliz de usar la skill Appify. No necesito crear mi propia CLI de Appify: la skill hace el trabajo mejor de lo que necesito." No matarse manteniendo infraestructura que alguien más ya resolvió es una decisión de ingeniería, no de pereza.
Por qué aprender
Porque la madurez de la capa de Herramientas consiste en saber elegir entre construir y reutilizar. Cada pieza adicional es una deuda que genera intereses. Detenerte a tiempo mantiene el OS ligero y te deja listo para la última capa de acción: los Agentes.
Conceptos clave
✅ Resumen del módulo
Siguiente módulo:
3.3 — Agentes: roles con criterio 🤖