El mecanismo es simple: MCP define un protocolo cliente-servidor donde un servidor MCP publica "tools" (funciones con schema de entrada y salida) y "resources" (datos legibles), y el cliente —Claude Code, Claude Desktop u otro host— las descubre y las invoca. En lugar de pegar la documentacion de tu API en el prompt y rezar, el modelo ve una lista tipada de acciones disponibles (por ejemplo crear_orden, leer_inventario, enviar_webhook) y elige cual usar con argumentos validados. Sobre Claude Code agregas subagentes —instancias que corren una subtarea en su propio contexto y devuelven solo el resultado— y skills —procedimientos reutilizables con instrucciones y scripts que se cargan bajo demanda. En un negocio esto se traduce en flujos como: un cron dispara el agente, este consulta una base via MCP, genera un entregable con una skill, lo publica via API de Netlify o Stripe, y notifica por un bot de Telegram. La decision entre MCP propio y API directa depende de reuso, control de permisos y cuanta logica de validacion necesitas encapsular fuera del prompt.
Olvidate de la definicion academica. MCP (Model Context Protocol) es un cable estandar entre un modelo como Claude y tus herramientas: tu CRM, tu base de datos, Stripe, una hoja de Google, tu propio backend. Antes de MCP, conectar un modelo a una herramienta significaba pegar documentacion de la API en el prompt y esperar que el modelo armara bien la llamada. Fragil, caro en tokens y dificil de controlar.
Con MCP cambias el modelo: levantas un servidor MCP que publica un catalogo de acciones tipadas —llamadas tools— como crear_factura, buscar_cliente o actualizar_inventario. Cada tool declara que recibe y que devuelve. El modelo no ve tu codigo: ve una lista de botones que puede apretar, con etiquetas claras y validacion. Tres primitivas componen el protocolo:
El valor para un negocio es de gobernanza: defines exactamente que puede tocar el agente y bajo que reglas. La logica de validacion vive en el servidor, no en la suerte del prompt. Eso es lo que convierte una demo en algo que dejas corriendo en produccion sin sudar.
No todo necesita un servidor MCP. La pregunta correcta es: ¿esta integracion se va a reusar y necesita reglas, o es un disparo unico?
Conecta la API a mano (dentro de un escenario de Make, un script de Python o una llamada HTTP directa) cuando:
Monta un servidor MCP propio cuando:
En la practica, empiezo por API directa para validar que el flujo aporta valor, y recien promuevo a MCP la pieza que se vuelve reusable y critica. Sobre-ingenierizar un MCP para un disparo unico es quemar tiempo; no encapsular una integracion que ya usan tres flujos es acumular deuda.
Claude Code no es solo un chat con tools. Dos piezas cambian la economia de automatizar de verdad: subagentes y skills.
Subagentes: un subagente corre una subtarea en su propio contexto aislado y devuelve solo el resultado. ¿Por que importa en un negocio? Porque las tareas reales generan ruido —logs, archivos intermedios, salidas de comandos— que envenena el contexto principal. Si delego 'investiga estos 20 perfiles y devolveme los 2 con mas fit' a un subagente, el contexto principal recibe dos nombres, no veinte paginas de scraping. Ademas puedo lanzar subtareas independientes en paralelo dentro del mismo turno.
Skills: una skill es un procedimiento reutilizable —una carpeta con instrucciones (cuando usarla y como) y opcionalmente scripts— que el agente carga bajo demanda segun la descripcion. Codificas el know-how una vez. Ejemplo de mi propio stack: una skill 'builder de curso' que toma un guion, genera el HTML, arma la portada y lo deja listo para subir; otra que regenera un catalogo desde el estado real del sistema.
El flujo tipico que armo: un cron en VPS dispara el agente, este usa tools MCP para leer datos, delega trabajo pesado a subagentes, ejecuta procedimientos con skills, publica via API (Netlify, Stripe) y notifica por un bot de Telegram. Cada pieza hace una cosa, verificable.
Demos hay muchas. Lo que cambia un negocio son flujos que corren solos y son idempotentes —los re-corres y no duplican ni rompen. Estos son patrones que construi para mis propios sistemas y que productizo para clientes:
El patron comun: el agente decide y orquesta, el codigo ejecuta lo irreversible, y siempre hay un punto de validacion antes de tocar dinero o publicar. Eso es la diferencia entre un juguete y algo que dejas corriendo.
No hay un stack universal; hay una logica de para que sirve cada pieza. El mio, que es el que llevo a produccion:
La regla que aplico: Make para orquestacion visual de bajo riesgo, codigo para logica critica, MCP para darle al agente acceso controlado a todo lo anterior. Y siempre un humano en el loop para lo que toca dinero o reputacion. No es el stack mas grande; es el que cada pieza se gana su lugar.
| Criterio | Servidor MCP propio | API directa (codigo) | Make / no-code |
|---|---|---|---|
| Mejor para | Capacidad reusable que el agente invoca en varios flujos | Integracion puntual con logica deterministica | Orquestacion visual multi-app de bajo riesgo |
| Reuso entre flujos | Alto: una tool, muchos consumidores | Bajo a medio: re-escribes o importas el script | Medio: clonas escenarios |
| Control de permisos | Fuerte: allowlist y validacion en el server | El que programes a mano | Limitado a lo que ofrece la app |
| Aislamiento de credenciales | Si: viven en el server, fuera del prompt | Si, en codigo/env | En el conector de la plataforma |
| Curva de montaje | Media: hay que escribir y mantener el server | Baja a media | Baja: visual, sin codigo |
| Auditabilidad / traza | Alta: cada llamada a tool queda registrada | La que implementes | Logs de ejecucion del escenario |
| Costo en tokens del prompt | Bajo: catalogo tipado, sin pegar docs | Variable segun como expongas la API | No aplica directamente |
| Cuando NO usarlo | Disparo unico que no se reusa | Cuando varios agentes necesitan la misma capacidad | Logica critica o irreversible (cobro, ordenes) |
Es un proceso que publica un catalogo de acciones (tools) y datos (resources) siguiendo el Model Context Protocol, para que un cliente como Claude Code las descubra e invoque. Corre sobre stdio (local) o HTTP/SSE (remoto) y actua como capa de interfaz controlada entre el modelo y tus sistemas. No reemplaza tu backend: lo expone con permisos explicitos.
Para usar flujos ya montados, no. Para disenar un servidor MCP propio o logica critica, si conviene programar o trabajar con alguien que lo haga. Muchas automatizaciones de bajo riesgo se resuelven con Make sin codigo; el MCP propio entra cuando necesitas reuso, validacion y control de credenciales.
Cuando la misma capacidad la van a usar varios flujos, cuando necesitas validar inputs antes de tocar produccion, o cuando quieres aislar credenciales fuera del prompt. Para un disparo unico dentro de un solo escenario, la API directa es mas rapida y suficiente.
El subagente corre la subtarea en contexto aislado y devuelve solo el resultado final, evitando que el ruido (logs, archivos, salidas intermedias) sature el contexto principal. Tambien permite paralelizar trabajo independiente. El agente principal se queda con la sintesis, no con el proceso.
Una skill es un procedimiento reutilizable empaquetado —instrucciones de cuando y como usarla, y opcionalmente scripts— que el agente carga bajo demanda segun su descripcion. Un prompt es texto que escribes en el momento. La skill codifica know-how una vez para reusarlo sin re-explicarlo en cada tarea.
Es seguro en la medida que disenes el servidor con validacion: allowlist de acciones, sin escritura destructiva por defecto, credenciales en variables de entorno del server y un humano en el loop para lo irreversible. El protocolo da el control; la seguridad la implementas tu en las tools.
Se combinan. Uso Make para orquestacion visual de bajo riesgo (triggers, ramas, reintentos multi-app) y Claude Code con MCP para decision, generacion y acceso controlado a sistemas. Make puede disparar al agente y el agente puede postear de vuelta a un escenario de Make.
Pipelines de contenido que generan y publican entregables a escala con deploy programado, alta de productos por API con tracking, scanners de datos que disparan acciones via webhook, y colas de revision con aprobacion humana. El patron: el agente orquesta, el codigo ejecuta lo critico, y hay validacion antes de lo irreversible.
Depende del alcance, pero el enfoque que aplico es incremental: primero un flujo simple con API directa que ya aporte valor, y recien promuevo a MCP las piezas que se vuelven reusables y criticas. Validar valor antes de sobre-ingenierizar acorta el tiempo a algo que sirve.
Porque construir y cerrar en la misma persona elimina handoffs: quien entiende el flujo tecnico es quien define el go-to-market, sin que se pierda contexto entre equipos. Para producto digital y automatizacion, esa asimetria es velocidad y coherencia. Es el modelo de Alter Ego: productizo lo que ya construi para mi.
Diagnóstico de 15 minutos, sin compromiso. Un operador, no una agencia.
Agendar diagnóstico →