Primero iniciá la hackathon
Tenés que completar tu nombre y contraseña antes de entrar al contenido del día.
¿Cómo hace el agente para tocar cosas fuera de tu proyecto?
En el Bloque 5 viste que Claude Code puede leer, escribir y correr comandos dentro de tu carpeta. Pero el trabajo real vive afuera: Drive, Slack, HubSpot, Basecamp, una base de datos, una API.
Hay dos formas de darle al agente esas capacidades. Las dos importan, y saber cuándo usar cuál te ahorra una hora de configuración innecesaria:
- CLIs — usar programas de terminal que ya existen (
git,gh,curl,aws,gcloud). - MCP (Model Context Protocol) — el protocolo estándar para conectar agentes a herramientas externas.
Y al final sumamos Skills: no son una tercera forma de dar capacidades, sino un mecanismo para empaquetar procedimientos que el agente aprende a ejecutar de forma consistente.
Los programas que ya instalaste sirven
Un CLI (Command Line Interface) es cualquier programa que se maneja desde la terminal. En el Bloque 2 ya instalaste varios: git, brew, uv, npx, tree. El agente puede ejecutar cualquiera de ellos vía su tool Bash — si vos sabés cómo invocar un CLI desde la terminal, podés enseñarle al agente a hacerlo.
CLIs que el agente usa seguido
git/gh→ el agente commitea, abre PRs, y revisa issues solo.curl→ para pegarle a cualquier API desde la terminal.- CLIs de servicios cloud:
aws,gcloud,doctl,stripe. - CLIs de utilidades:
jq(parsear JSON),rg(ripgrep, búsqueda rápida),fd(find moderno).
La ventaja: si ya existe un CLI para lo que querés hacer, no hay que configurar nada nuevo. El agente ya lo puede usar. No hay servers, no hay auth nueva, no hay config files.
El protocolo "oficial" para darle herramientas al agente
MCP (Model Context Protocol) es el protocolo estándar que Anthropic liberó en 2024 para que los agentes de AI se conecten a herramientas y datos externos. En vez de pedirle al agente "corré este comando con estos flags", le das un servidor MCP pre-armado (para Drive, Slack, HubSpot, lo que sea) y el agente descubre solo qué puede hacer con él.
Analogía: si el agente es una persona inteligente, un CLI es como enseñarle a usar una herramienta específica, y MCP es como darle las llaves de toda una oficina — entra, ve qué hay, y usa lo que necesita.
Qué te da MCP que un CLI no
- Auto-descubrimiento — el agente consulta al server "¿qué podés hacer?" y recibe una lista estructurada de tools (acciones), resources (datos accesibles) y prompts (templates reusables).
- Sin escribir el comando "a mano" — cuando usás un CLI, alguien tiene que saber exactamente cómo invocarlo. Con MCP, el agente lo averigua solo.
- Tipos y validación — cada tool expone qué parámetros acepta y de qué tipo. El agente no se inventa flags que no existen.
- Ecosystem creciente — hay cientos de MCP servers pre-hechos publicados (mirá mcp.so).
Imprescindible · darle un navegador al agente
De todos los MCPs/CLIs que existen, hay dos que le cambian la vida al agente porque le dan lo que más le falta por default: ojos y manos en la web. Si instalás uno solo este viernes, que sea uno de estos.
- Playwright MCP — servidor MCP oficial de Microsoft. El agente abre un Chromium real, navega, hace click, rellena formularios, saca screenshots, lee el DOM. Ideal para QA, scraping autenticado, dogfooding de tus propias apps, o cualquier flujo web que antes hacías a mano. Repo: microsoft/playwright-mcp.
- agent-browser — CLI de Anthropic pensado específicamente para que un agente maneje un browser (incluye apps de Electron como Slack, VS Code, Figma). Más liviano que Playwright si sólo querés una sesión controlada desde la terminal. Instalable como Skill en Claude Code.
Por qué son clave: el agente ya sabe leer archivos locales y pegarle a APIs. Lo que no sabe por default es "abrí esta página, logueate con mi sesión, y contame qué dice". Con Playwright o agent-browser, pasa a poder hacer cualquier cosa que vos harías con el browser abierto.
Cuándo usar CLI y cuándo usar MCP
| Necesitás que el agente… | Usás |
|---|---|
| Haga algo que ya se hace con un CLI conocido (git, curl, aws) | CLI directo — más rápido, no configura nada |
| Se conecte a un servicio SaaS (Drive, Slack, Notion, HubSpot) | MCP — ya hay servers pre-hechos |
| Acceda a un sistema interno tuyo repetidas veces | MCP custom — lo armás una vez y lo reusás |
| Haga una llamada puntual a una API | curl por CLI — más simple que un MCP |
| Tenga acceso a tus archivos locales | Ya lo tiene vía las 4 tools (Read/Write/Bash/Grep) |
| Navegue la web, haga click, complete formularios | Playwright MCP o agent-browser (CLI) |
Conectar el agente a un servicio real
Vamos a hacer dos cosas: primero, el agente usa un CLI que ya tenés (gh, el CLI de GitHub). Después, configuramos un MCP server para un servicio SaaS de tu área.
Instalar gh y loguearte
brew install gh # si no lo tenías
gh auth login # seguí el flow interactivo
gh repo list # verificá que te devuelve tus repos
Ahora abrí Claude Code en tu proyecto del Bloque 3 y pedile:
Creá un repo público en GitHub llamado "hackathon-prueba" con el contenido
de esta carpeta, hacé push, y pasame el link del repo.
El agente va a usar gh repo create, git remote add, git push, y te va a dar la URL. Eso es un CLI actuando como extensión del agente. No necesitaste MCP.
Configurar un MCP server
Hay tres caminos para enchufar un MCP a Claude Code. Los tres conviene conocerlos — el agente los automatiza, pero si sabés qué pasa por debajo podés debuggear cuando algo no engancha.
A · Por CLI — el comando oficial, el más directo:
claude mcp add <nombre> <comando para correr el server>
# Ejemplo real (Playwright MCP oficial de Microsoft):
claude mcp add playwright npx @playwright/mcp@latest
# Desde dentro de Claude Code, para ver qué MCPs están conectados:
/mcp
B · Editando .mcp.json — archivo en el root del proyecto. Se commitea con git, así tu equipo hereda los MCPs al clonar sin tener que configurar uno por uno. Misma lógica que un package.json.
C · Pidiéndoselo al agente — "instalame el MCP de Playwright en este proyecto" y lo hace solo (corre A o B por vos). Súper cómodo, pero saber A y B te salva cuando el agente se traba o querés revisar qué dejó configurado.
En vivo vamos a configurar uno que aplique a tu área — el catálogo de opciones depende de lo que cada líder necesite. Algunos candidatos del catálogo oficial:
| Área | MCP server candidato |
|---|---|
| Data / RevOps | HubSpot, Google Sheets, Postgres |
| PPC / SEO | Google Analytics, Search Console, Ads |
| Creative / People | Drive, Notion, Slack |
| Ops / Finanzas | Filesystem local, Sheets, QuickBooks |
El catálogo completo vive en mcp.so. Cada server trae sus propias instrucciones de instalación + credenciales.
Enseñarle al agente tareas repetibles
Una Skill es una carpeta con instrucciones + scripts + archivos que le enseña al agente cómo hacer una tarea específica de forma consistente. No es una nueva capacidad — es un procedimiento empaquetado que reusa las tools y MCPs que ya tenés.
Cómo se ven por dentro
mi-skill/
├── SKILL.md # instrucciones en lenguaje natural
├── templates/ # plantillas reusables
│ └── reporte.md
├── scripts/ # helpers ejecutables
│ └── limpiar_csv.py
└── datos/
└── brand-guidelines.md
El mecanismo — progressive disclosure
El agente escanea las Skills disponibles y carga sola la que corresponde según lo que le pidas. No es que tenga todas en contexto todo el tiempo (sería desperdicio de tokens) — mira los nombres y descripciones, y cuando detecta "esto es un reporte PPC", carga SKILL.md de la Skill de PPC.
Skill vs comando — la confusión más común
Al principio se mezclan porque las dos suman capacidades al agente desde Claude Code, pero el mecanismo es distinto.
- Un comando (
/mi-comando) es un atajo que vos disparás a mano desde el chat. Corre un prompt pre-armado al que podés pasarle argumentos. Sirve para flows puntuales que arrancás vos. - Una Skill es un procedimiento + conocimiento empaquetado. Tiene doble naturaleza: es invocable —el agente la carga y la ejecuta cuando detecta que aplica a tu pedido— y además funciona como fuente de conocimiento consultable que otros agentes o sub-agentes leen en medio de una tarea más grande para saber cómo hacer algo bien.
La clave: un comando lo invocás siempre vos. Una skill la invoca el agente cuando le hace falta, incluso en el medio de una tarea que no la nombra directamente — porque para resolverla necesita el know-how que dejaste adentro del SKILL.md.
Skill vs MCP — la diferencia que importa
- Skill = "así se hace X tarea" (conocimiento + procedimiento).
- MCP = "acá tenés acceso a X herramienta externa" (conexión a un sistema).
Las dos cosas se combinan: una Skill puede usar herramientas de MCP por debajo. Ejemplo: una Skill de "Reporte PPC semanal" puede leer de un MCP de Google Ads, escribir en un MCP de Drive, y seguir una plantilla que vive en la propia Skill.
Tres caminos para meterle una Skill al agente
Una skill no es más que una carpeta. Lo único que cambia entre los tres caminos es de dónde viene la carpeta y dónde termina.
A · Tirando la carpeta vos mismo
Si tenés un folder con un SKILL.md adentro, el agente lo levanta automáticamente si está en alguna de estas dos rutas:
~/.claude/skills/mi-skill/→ skills globales, disponibles desde cualquier carpeta. Usalo para lo que te sirve en todo proyecto (ej: "Reporte PPC Growketing", "Tono de voz de la marca")..claude/skills/mi-skill/dentro del proyecto → skills del repo, sólo aplican ahí. Se commitean con git. Ideal para convenciones de un cliente específico o procedimientos atados a ese código.
Esto es el mismo patrón de dotdirs que venís viendo desde B1: .gitconfig global vs .git/ del proyecto, .zshrc global vs .env del proyecto. Mismo esquema, scope distinto. Si la skill sirve para cualquier trabajo tuyo, va en global; si es específica a un repo/cliente, va versionada con el proyecto.
B · Desde el registry público (skills.sh)
Vercel mantiene un registro público con miles de skills publicadas (skills.sh) y un CLI que las instala en la carpeta correcta por vos. Es multi-cliente (sirve para Claude Code, Cursor, Cline, etc.). No hace falta instalar nada global — corre con npx:
# Buscar skills por tema
npx skills find pdf
# Instalar una skill global para Claude Code
npx skills add anthropics/skills@pdf -g -a claude-code -y
# Meta-skill: una skill que te ayuda a encontrar otras skills
npx skills add vercel-labs/skills@find-skills -g -a claude-code -y
# Ver qué hay y actualizar
npx skills check
npx skills update
C · Pidiéndoselo al agente
"Instalame la skill para generar PDFs y dejámela global para Claude Code" — y el agente corre el npx skills add ... por vos. Funciona bárbaro, pero saber A y B te da control: así podés revisar qué quedó instalado, moverlo entre scopes, o escribir skills propias desde cero.
Ojo con /plugin: Claude Code tiene su propio marketplace de plugins (comando /plugin dentro del chat) que es distinto a skills.sh. Los plugins empaquetan hooks, slash commands y MCPs juntos; es el canal oficial de Anthropic. Regla práctica por ahora: skills con npx skills add, plugins con /plugin.
MCP explicado por el equipo que lo creó
Si hay un solo video del pre-work que mirar para este bloque, que sea éste. Es un panel oficial de Anthropic donde David Soria Parra (co-creador de MCP), Theo Chu y Alex Albert explican qué problema resuelve MCP y cómo está cambiando cómo las apps de AI se conectan con herramientas externas.
Para los que van rápido
- Configurá un segundo MCP server de otro tipo. Si ya tenés Drive, probá Slack o Notion.
- Probá encadenar: el agente lee datos de una fuente (MCP 1), los procesa, escribe el resultado en otra (MCP 2). Esto es el patrón base de cualquier agente útil.
- Explorá el repo anthropics/skills — tiene ejemplos reales de Skills (Excel, PDF, PowerPoint) con el código disponible. Leé cómo están escritos los SKILL.md, es plantilla oro.
- Ojéa el registro mcp.so para ver qué MCP servers existen en tu área.
- Escribí tu primera Skill simple: un
SKILL.mdcon las convenciones de un tipo de reporte tuyo, y probá pedirle al agente que la use.
¿Lo hiciste y lo entendés?
Lo mínimo que tenés que tener para el Milestone: 1 MCP server o 1 Skill configurada y probada al menos una vez (lo que más te sirva a tu área).
Docs, catálogos y cursos
Para usar hoy
/pluginPara entender qué son
Dónde viven los datos que movés a mano
MCP y Skills son herramientas para conectar al agente con lo que ya hacés. Identificar ese "lo que ya hacés" es la mitad del trabajo antes del build libre.
- Mirá tu dock o las tabs abiertas del browser: ¿cuáles de esas herramientas tienen datos que vivís abriendo y copiando a otro lado?
- ¿Qué proceso hacés siempre igual en tu área? Si tuvieras que enseñárselo a alguien nuevo paso por paso, ya estás escribiendo un Skill.
- ¿Cuántas veces por semana hacés "copio de acá, pego allá"? Cada una es un MCP o una automatización potencial.
- ¿De qué herramientas ya tenés accesos programáticos (HubSpot, Google Ads, Meta Ads, GA, Notion, GitHub)? Son la materia prima para conectar un agente.
- Si tuvieras que listar los 3 servicios SaaS donde más tiempo pasás por semana, ¿cuáles son? Esos son los candidatos a MCP más rentables para vos.