Me quedé mirando la pantalla durante treinta segundos, genuinamente confundido.
Claude acababa de crear una nota en mi bóveda de Obsidian — no porque copié y pegué texto, no porque usé alguna integración de Zapier — sino porque se lo pedí. En español llano. "Crea una nota sobre café de prensa francesa." Y ahí estaba, en mi bóveda como si la hubiera escrito yo mismo.
Eso fue hace tres semanas. Desde entonces, he conectado Claude a mi gestor de tareas, mi calendario, un web scraper, transcripciones de YouTube y — no estoy exagerando — Kali Linux. Mi IA ahora puede hackear por mí. Bueno, más o menos. Pero el punto es válido: algo fundamental cambió, y la mayoría de los desarrolladores con los que hablo aún no se han dado cuenta.
El cambio tiene nombre. Se llama MCP — el Model Context Protocol. Y una vez que entiendes lo que hace, te darás cuenta de que la brecha entre "chatbot de IA" y "agente de IA" no es algún problema de investigación lejano. Es un archivo de configuración.
Esto es lo que no esperaba: lo más difícil no fue la tecnología. Lo más difícil fue desaprender cómo pensaba sobre la IA.
El Problema del Que Nadie Habla
Vi recientemente el análisis de NetworkChuck sobre MCP — una inmersión profunda de 38 minutos que ya superó los 1.2 millones de vistas — y algo que dijo al principio hizo clic en mi mente de una manera que meses leyendo documentación no habían logrado.
Comparó los LLMs con personas. Quédate conmigo aquí.
Cuando tú o yo queremos usar una herramienta — digamos, ClickUp para gestión de tareas — interactuamos a través de una interfaz gráfica. Botones, menús, arrastrar y soltar. La GUI abstrae toda la complejidad subyacente. No necesitamos conocer el esquema de la base de datos ni los endpoints de la API. Simplemente hacemos clic.
Los LLMs odian las GUIs. Técnicamente pueden interactuar con ellas (existen agentes basados en capturas de pantalla), pero es lento, poco confiable, y se siente como enseñar a alguien a conducir mostrándole fotos de volantes.
Bien, ¿entonces dales APIs? Para eso están las APIs — para que un programa hable con otro programáticamente. Y sí, esto funciona. Pero aquí está el problema que Chuck clavó perfectamente: cada API tiene cientos de endpoints con esquemas de autenticación únicos, formatos de parámetros y estructuras de respuesta. Solo la API de ClickUp es masiva. También la de Obsidian. Y la de GitHub. Y la de cualquier otra herramienta que quieras que tu IA use.
Para conectar un LLM a solo cinco herramientas mediante APIs crudas, necesitarías escribir código de integración personalizado para cada una, manejar la autenticación para cada una, parsear las respuestas de cada una, y luego de alguna manera enseñarle al LLM qué endpoints llamar y cuándo.
Ya lo he hecho. Para un proyecto de cliente el año pasado, pasé dos semanas construyendo una capa personalizada de llamada a herramientas para GPT-4 que se conectaba a tres APIs internas. Dos semanas. Tres herramientas.
MCP cambia esa ecuación por completo.
Qué es Realmente MCP (Sin el Hype)
El Model Context Protocol es, en esencia, una interfaz estandarizada entre LLMs y herramientas externas. Anthropic lo creó, pero se ha convertido en un estándar de la industria adoptado por OpenAI, Google y básicamente todas las empresas de herramientas de IA.
Piénsalo como USB-C para herramientas de IA. Antes de USB-C, cada dispositivo tenía su propio conector propietario. Necesitabas un cajón lleno de cables. USB-C dijo: "Aquí hay un estándar. Todos úsenlo." MCP hace lo mismo para la comunicación entre LLMs y herramientas.
Aquí está la arquitectura en términos simples:
LLM (Claude, GPT, Llama)
↕ habla el protocolo MCP
MCP Server (se ejecuta local o remotamente)
↕ maneja todo lo complicado de la API
Herramienta Externa (Obsidian, ClickUp, GitHub, etc.)
El servidor MCP se ubica entre tu IA y las herramientas que necesita. Maneja la autenticación, las llamadas API, el parseo de respuestas — todo. El LLM no necesita saber nada sobre endpoints REST o tokens OAuth. Solo ve una lista de "herramientas" disponibles descritas en lenguaje sencillo:
create_note— Crear una nueva nota en la bóvedasearch_vault— Buscar contenido en todas las notasappend_content— Agregar contenido a una nota existente
El LLM elige la herramienta correcta, pasa los parámetros y recibe resultados estructurados. Eso es todo. Sin código personalizado. Sin luchar con APIs.
Pero aquí está la parte que me hizo prestar mucha atención — y esto conecta con algo mucho más grande.
De Chatbot a Agente: Los Tres Niveles
Mientras configuraba servidores MCP, me encontré con la explicación de Jeff Su sobre agentes de IA — un video que ha alcanzado casi 4 millones de vistas — y cristalizó algo que venía sintiendo pero no podía articular.
Jeff divide la IA en tres niveles, y una vez que los ves, no puedes dejar de verlos:
Nivel 1: LLM Básico. Le das entrada, obtienes salida. ¿Le pides a ChatGPT que redacte un email? Genial. ¿Le preguntas cuándo es tu próxima reunión? Falla. No lo sabe. No tiene acceso. Solo genera texto basado en datos de entrenamiento.
Nivel 2: Flujo de Trabajo de IA. Agregas caminos predefinidos. "Cuando el usuario pregunte sobre eventos del calendario, primero consulta Google Calendar, luego responde." Esto funciona — hasta que el usuario pregunta algo que no anticipaste. "¿Cómo estará el clima el día de mi reunión?" Tu flujo solo conoce Google Calendar, no APIs de clima. Cada nueva capacidad requiere que un humano agregue manualmente otro camino.
Aquí está la clave del análisis de Jeff: no importa cuántos pasos agregues — cientos, miles — si un humano es quien decide qué camino seguir, sigue siendo solo un flujo de trabajo. No un agente.
Nivel 3: Agente de IA. El LLM mismo decide qué hacer. Razona ("Necesito datos del calendario Y datos del clima"), selecciona herramientas ("Usaré la API de Google Calendar primero, luego un servicio de clima"), ejecuta, evalúa el resultado e itera si es necesario.
El framework detrás de esto se llama ReAct — Reason and Act (Razonar y Actuar). El agente piensa en lo que necesita, toma acción usando herramientas, observa el resultado y decide si continuar o dar una respuesta final.
Y aquí es donde MCP se convierte en la pieza que faltaba. Porque un agente de IA necesita herramientas para actuar. Sin herramientas, solo está pensando en voz alta. MCP le da manos.
Configurando MCP con Docker (La Parte Práctica)
Lo aprendí por las malas: no intentes instalar servidores MCP manualmente en tu primer intento. Usa Docker. Maneja el aislamiento, las dependencias y la limpieza automáticamente.
Este es mi proceso exacto de configuración:
Paso 1: Instalar Docker Desktop
Descárgalo del sitio oficial para tu sistema operativo. En Mac:
# Descarga e instala Docker Desktop desde docker.com/desktop
# O vía Homebrew:
brew install --cask docker
# Verificar instalación
docker --version
# Docker version 28.x.x
# Habilitar MCP Toolkit en Docker Desktop:
# Settings → Beta Features → Docker MCP Toolkit → Enable
En Windows, necesitarás WSL 2 o Hyper-V como backend primero. Linux es directo — solo instala Docker Engine y Desktop.
Paso 2: Explorar el Catálogo MCP
Docker Desktop ahora incluye un catálogo MCP — una lista curada de servidores MCP oficiales. Abre Docker Desktop, ve a la sección MCP Toolkit y explora el catálogo. Me sorprendió genuinamente lo que hay disponible:
- Obsidian — Acceso completo a la bóveda (leer, escribir, buscar)
- Brave Search — Búsqueda web con privacidad
- Fetch — Obtener contenido de cualquier URL
- YouTube Transcripts — Extraer transcripciones de cualquier video
- DuckDuckGo — Buscar sin claves API
- Airbnb — Buscar alojamientos (sí, en serio)
Agregar un servidor es un solo clic. Algunos necesitan claves API (Brave, por ejemplo), pero muchos funcionan directamente.
Paso 3: Conectar Tu Cliente LLM
Docker MCP Toolkit soporta múltiples clientes:
- Claude Desktop (el nivel gratuito funciona)
- Cursor (para trabajo enfocado en código)
- LM Studio (para modelos locales como Llama)
Haz clic en "Connect" junto a tu cliente. Docker actualiza automáticamente el archivo de configuración MCP que tu cliente lee. Para Claude Desktop, este archivo está en ~/Library/Application Support/Claude/claude_desktop_config.json en Mac.
Así se ve la configuración internamente:
{
"mcpServers": {
"obsidian": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "OBSIDIAN_API_KEY=your-key-here",
"mcp/obsidian"
]
},
"fetch": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/fetch"]
},
"youtube-transcript": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/youtube-transcript"]
}
}
}
Cada servidor se ejecuta como un contenedor Docker aislado. Cuando Claude necesita usar una herramienta, levanta el contenedor, hace la llamada y el contenedor se apaga. Limpio. Aislado. Sin conflictos de dependencias.
Paso 4: Probarlo
Reinicia Claude Desktop. Haz clic en el ícono de configuración — deberías ver "MCP Docker" listado. Haz clic para verificar que tus herramientas están cargadas.
Luego simplemente pregunta: "Busca en mi bóveda de Obsidian notas sobre planificación de proyectos."
Claude reconocerá que tiene la herramienta search_vault, pedirá permiso para usarla (solo la primera vez si así lo eliges) y devolverá resultados de tu bóveda real.
La primera vez que vi esto funcionar, literalmente dije "¿Me estás tomando el pelo?" en voz alta. En una habitación vacía. A las 2 AM.
Construyendo un Servidor MCP Personalizado
El catálogo es genial para herramientas comunes. Pero el verdadero poder se desbloquea cuando construyes servidores personalizados para tus necesidades específicas.
El video de NetworkChuck mostró algo increíble: construyó un servidor MCP que envuelve herramientas de Kali Linux. Su IA podía ejecutar escaneos nmap, usar Metasploit y enumerar objetivos — todo a través de lenguaje natural.
Yo construí algo menos dramático pero más práctico para mi trabajo diario: un servidor MCP que envuelve la API del CMS de mi blog. Aquí está el esqueleto:
#!/usr/bin/env python3
"""Servidor MCP personalizado para el CMS del blog mejba.me."""
import json
import httpx
from mcp.server import Server
from mcp.types import Tool, TextContent
app = Server("blog-cms")
BASE_URL = "https://mejba.me/api"
API_TOKEN = "your-api-token"
@app.list_tools()
async def list_tools():
return [
Tool(
name="create_draft",
description="Create a new blog post draft with title, content, and tags",
inputSchema={
"type": "object",
"properties": {
"title": {"type": "string", "description": "Post title"},
"content": {"type": "string", "description": "Markdown content"},
"tags": {"type": "array", "items": {"type": "string"}}
},
"required": ["title", "content"]
}
),
Tool(
name="list_recent_posts",
description="List the most recent blog posts with their status",
inputSchema={
"type": "object",
"properties": {
"limit": {"type": "integer", "default": 10}
}
}
),
Tool(
name="get_post_analytics",
description="Get view count and engagement metrics for a post",
inputSchema={
"type": "object",
"properties": {
"slug": {"type": "string", "description": "Post slug"}
},
"required": ["slug"]
}
)
]
@app.call_tool()
async def call_tool(name: str, arguments: dict):
headers = {"Authorization": f"Bearer {API_TOKEN}"}
if name == "create_draft":
response = httpx.post(
f"{BASE_URL}/posts",
headers=headers,
json={
"title": arguments["title"],
"content": arguments["content"],
"tags": arguments.get("tags", []),
"status": "draft"
}
)
data = response.json()
return [TextContent(
type="text",
text=f"Draft created: {data['slug']} (ID: {data['id']})"
)]
elif name == "list_recent_posts":
limit = arguments.get("limit", 10)
response = httpx.get(
f"{BASE_URL}/posts?limit={limit}", headers=headers
)
posts = response.json()
result = "\n".join(
f"- [{p['title']}] ({p['status']}) - {p['views']} views"
for p in posts
)
return [TextContent(type="text", text=result)]
elif name == "get_post_analytics":
response = httpx.get(
f"{BASE_URL}/posts/{arguments['slug']}/analytics",
headers=headers
)
data = response.json()
return [TextContent(
type="text",
text=json.dumps(data, indent=2)
)]
if __name__ == "__main__":
import asyncio
from mcp.server.stdio import stdio_server
asyncio.run(stdio_server(app))
Envuelve esto en un Dockerfile, y cualquier cliente compatible con MCP puede usar el CMS de tu blog a través de lenguaje natural. "Oye Claude, crea un borrador de post sobre MCP con estas etiquetas." Listo.
El patrón funciona para cualquier cosa con una API: dashboards internos, bases de datos, dispositivos IoT, pipelines de CI/CD. Si tiene una API, puedes envolverlo en un servidor MCP en menos de una hora.
Los Errores Honestos que Cometí
Quiero ser transparente sobre lo que me hizo tropezar, porque creo que son errores que la mayoría de la gente cometerá.
Error 1: Tratar los agentes MCP como automatización tradicional. Mi primer instinto fue construir flujos rígidos — "Cuando digo X, haz Y." Pero todo el punto del paradigma de agentes es que el LLM decide qué herramientas usar y cuándo. Seguía sobre-restringiendo las cosas. Los mejores resultados llegaron cuando le di a Claude un objetivo y lo dejé determinar la secuencia de herramientas.
Error 2: Ignorar el modelo de permisos. Los servidores MCP pueden acceder a tus archivos, tus APIs, tu red. Claude Desktop pide permiso antes de cada uso de herramienta (a menos que lo permitas permanentemente). Desactivé las solicitudes de confirmación por comodidad y luego olvidé que tenía un servidor MCP conectado a mi correo. Claude amablemente "organizó" mi bandeja de entrada basándose en un comentario casual que hice. Lección aprendida: mantén los permisos estrictos hasta que confíes en el flujo de trabajo.
Error 3: Esperar perfección de los modelos locales. Intenté ejecutar agentes conectados a MCP a través de LM Studio con Llama 3.1. La selección de herramientas fue notablemente peor que con Claude. Los modelos locales funcionan, pero necesitan prompts más explícitos sobre cuándo y cómo usar herramientas. Claude y GPT-4 son significativamente mejores en la selección autónoma de herramientas — por ahora.
Aquí va una opinión controvertida: creo que la mayoría de los productos de "agentes de IA" que se venden ahora son en realidad flujos de trabajo de Nivel 2 disfrazados de agentes. Siguen caminos predefinidos con algo de toma de decisiones de LLM espolvoreada. Los verdaderos agentes de Nivel 3 — donde el LLM genuinamente razona sobre la selección de herramientas, el orden de ejecución e itera autónomamente — son raros fuera de demos de investigación y un puñado de implementaciones reales.
Dicho esto, MCP es la capa de infraestructura que hace posibles los agentes reales. El protocolo existe. Las herramientas existen. Lo que está alcanzando el ritmo es la capacidad de razonamiento de los propios modelos.
Cómo Se Ve Esto en la Práctica
Después de tres semanas construyendo flujos de trabajo basados en MCP, aquí está mi antes/después concreto:
Investigación para el blog — Antes: 2-3 horas viendo videos de YouTube manualmente, tomando notas, cruzando referencias con documentación. Después: 25 minutos. Claude extrae transcripciones de YouTube vía MCP, busca en mi bóveda de investigación de Obsidian notas relacionadas y redacta un esquema estructurado. Yo edito desde ahí.
Configuración de proyectos de clientes — Antes: 45 minutos creando repos, configurando CI/CD, agregando al rastreador de proyectos. Después: 8 minutos. Claude crea el repo en GitHub, inicializa la estructura del proyecto, lo agrega a ClickUp con hitos y envía una notificación por Slack al equipo. Todo a través de herramientas conectadas por MCP.
Preparación del standup diario — Antes: 15 minutos revisando ClickUp, PRs de GitHub y canales de Slack. Después: 2 minutos. "¿En qué trabajé ayer y qué está pendiente para hoy?" Claude revisa los tres y me da un resumen.
Los ahorros de tiempo son reales. No teóricos. No "hasta X%." Estos son mis números reales de las últimas tres semanas.
Pero — y esto importa — la configuración inicial me tomó un fin de semana completo. Instalar Docker, configurar servidores, probar conexiones, depurar cuando las cosas no funcionaban. Una vez que está corriendo, es mágico. Llegar ahí requiere paciencia.
Hacia Dónde Va Todo Esto
NetworkChuck mencionó algo al final de su video que creo que la mayoría de los espectadores pasaron por alto: el Docker MCP Gateway. Esto hace que tus servidores MCP locales sean accesibles remotamente — lo que significa que herramientas como n8n, Make.com o cualquier plataforma de automatización externa pueden conectarse a tus servidores MCP a través de la red.
Piensa en lo que eso significa. Tu agente de IA ya no está limitado a tu máquina local. Podrías tener un flujo de trabajo en n8n que active un agente de Claude que use tus servidores MCP personalizados ejecutándose en un VPS. El agente razona sobre qué hacer, usa herramientas a través de MCP y devuelve resultados — todo sin intervención humana.
Aún no estamos ahí para la mayoría de los casos de uso en producción. Pero la brecha entre "demo" y "producción" se está cerrando más rápido de lo que esperaba.
Si te llevas algo de este post: no esperes hasta que los agentes de IA estén "listos." La infraestructura — MCP, contenedores Docker, LLMs con llamada a herramientas — está aquí ahora. Los desarrolladores que aprendan este stack hoy tendrán una ventaja masiva cuando las capacidades de razonamiento se pongan al día.
Estoy apostando mi flujo de trabajo a ello. Y honestamente, tres semanas después, ya está dando resultados.
Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (builds e integraciones personalizadas): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
