MCP explicado para developers: conecta Claude a tus herramientas
Hace unos meses estaba trabajando con Claude Code en un proyecto con Supabase. Quería que el agente pudiese consultar la base de datos, leer el schema, revisar los registros. Lo normal cuando construyes algo de verdad.
El problema: Claude no podía llegar a Supabase por sí solo. Necesitaba que yo le pasase el contexto a mano — copiar y pegar schema, copiar y pegar queries, copiar y pegar resultados. El LLM hacía el trabajo intelectual, pero la conexión a las herramientas era un cuello de botella manual y frustrante.
Eso era la vida antes de MCP (Model Context Protocol).
Hoy, con el servidor MCP de Supabase configurado en Claude Code, el agente puede leer tablas, ejecutar queries y revisar logs sin que yo mueva un dedo. La diferencia no es pequeña. Es el salto entre un asistente que responde preguntas y un agente que trabaja de verdad.
El problema que MCP viene a resolver
Antes de MCP, si querías conectar un LLM a una herramienta externa — GitHub, una base de datos, Slack, tu sistema de archivos — tenías que construir esa integración desde cero para cada caso.
Cada proveedor de LLM tenía su forma de hacer “function calling”. OpenAI tenía la suya. Anthropic tenía la suya. Google tenía la suya. Y cada herramienta que querías conectar necesitaba código custom adaptado a ese proveedor específico.
El resultado: ecosistemas fragmentados. Integraciones que había que reescribir al cambiar de modelo. Código duplicado en cada proyecto. Y una fricción enorme para cualquier developer que quisiese construir algo más allá del chat básico.
MCP es la respuesta a ese problema. Un protocolo único, abierto y estandarizado para que cualquier LLM se comunique con cualquier herramienta. Escribe el servidor una vez. Funciona con cualquier cliente compatible.
Qué es MCP exactamente
Model Context Protocol es un protocolo abierto — especificación pública, SDK con licencia MIT — creado por Anthropic en noviembre de 2024 y adoptado por la industria. Define cómo los LLMs se comunican con herramientas y fuentes de datos externas.
La arquitectura tiene dos piezas:
- Cliente MCP — la aplicación host que aloja al LLM (Claude Code, Claude Desktop). Es quien inicia la conexión, gestiona qué servidores están disponibles y enruta las llamadas del modelo a las herramientas.
- Servidor MCP — el servicio que expone las herramientas. Puede ser Supabase, GitHub, tu sistema de archivos, Notion, Slack, o cualquier cosa que hayas construido tú mismo.
El flujo de una interacción con MCP es el siguiente:
- El usuario hace una petición a Claude: “¿Cuántos usuarios se registraron esta semana?”
- Claude detecta que necesita datos de la base de datos.
- La aplicación host enruta la llamada al servidor MCP de Supabase.
- El servidor ejecuta la query y devuelve los resultados.
- Claude recibe la respuesta y continúa la conversación con datos reales.
Todo esto ocurre dentro de la misma sesión, de forma transparente para el usuario. La especificación completa del protocolo está disponible en modelcontextprotocol.io, mantenida como estándar abierto.
MCP vs Function Calling: la diferencia que importa
Si llevas tiempo trabajando con LLMs probablemente conoces el concepto de function calling — la capacidad de un modelo de invocar funciones definidas por el developer.
La confusión es comprensible. MCP y function calling resuelven el mismo problema superficialmente. Pero hay una diferencia fundamental:
| Criterio | Function Calling | MCP |
|---|---|---|
| Compatibilidad | Propietario por proveedor | Protocolo abierto |
| Portabilidad | Reescribir al cambiar de modelo | Un servidor, cualquier cliente |
| Mantenimiento | Código duplicado por proveedor | Único punto de actualización |
| Adopción | Fragmentada | Claude Code, Cursor y más |
Function calling es propietario. La especificación de cómo defines una función para OpenAI no es la misma que para Anthropic. Si cambias de modelo, reescribes las integraciones.
MCP es el estándar universal. El servidor MCP que escribas hoy para conectar Claude a tu base de datos funciona también con cualquier otro cliente MCP que aparezca mañana. El servidor no sabe ni le importa qué LLM hay al otro lado.
Es la diferencia entre construir sobre propietario y construir sobre estándar. La misma diferencia que existe entre HTTP y el protocolo interno de un servicio concreto.
Si estás construyendo herramientas que los LLMs van a usar en producción, MCP es la apuesta correcta. Es la razón por la que en el curso Construye con IA trabajamos con MCP desde el principio — no porque sea lo más nuevo, sino porque es lo que tiene sentido en un stack real.
Casos de uso reales para developers
Supabase MCP. Claude puede leer el schema de tu base de datos, ejecutar queries, revisar los logs de error, inspeccionar las políticas RLS. Cuando estás debuggeando un problema en producción, tener al agente con acceso directo a la base de datos no es un lujo — es lo que separa minutos de horas.
GitHub MCP. Claude puede leer Pull Requests, crear issues, revisar el historial de commits, comentar en code reviews. Si trabajas en un equipo o gestionas un proyecto open source, esto te cambia el flujo de trabajo.
Filesystem MCP. Claude puede leer y escribir archivos en tu proyecto directamente. Esto es lo que usa Claude Code por defecto — el acceso al sistema de archivos es un servidor MCP. Cuando le dices a Claude “edita este archivo”, hay un servidor MCP detrás gestionando esa operación.
Notion o Confluence MCP. Claude puede leer tu documentación, buscar en tus notas, actualizar páginas. Útil si tienes tu spec o tus decisiones de arquitectura en Notion y quieres que el agente las tenga en contexto sin tener que copiarlas manualmente.
Slack MCP. Claude puede leer canales, buscar mensajes, enviar notificaciones. Si construyes pipelines de automatización, esto es la pieza que conecta el agente con tu equipo.
El patrón es siempre el mismo: en lugar de que tú seas el intermediario entre el LLM y la herramienta, el protocolo gestiona esa conexión. Tu rol pasa de “copy-paste operator” a alguien que define qué herramientas el agente puede usar y con qué permisos.
Cómo configurar un servidor MCP en Claude Code
La parte práctica. Hay dos formas de configurar servidores MCP en Claude Code:
Opción 1 — Configuración global (claudedesktopconfig.json) Esta configuración aplica a todas tus sesiones de Claude Code. El archivo vive en:
- macOS:
~/Library/Application Support/Claude/claudedesktopconfig.json - Windows:
%APPDATA%\Claude\claudedesktopconfig.json
Opción 2 — Configuración por proyecto (.mcp.json) Un archivo .mcp.json en la raíz de tu proyecto. Solo aplica a ese proyecto. Es la opción que recomiendo — el contexto de las herramientas debe ser específico al proyecto, no global.
Ejemplo práctico: MCP de filesystem
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/bezael/projects/mi-proyecto"
]
}
}
}
Con esto configurado, Claude puede leer y modificar archivos dentro de la ruta que especifiques. No tiene acceso a nada fuera de ese directorio — los permisos los defines tú.
Ejemplo: MCP de Supabase
{
"mcpServers": {
"supabase": {
"command": "npx",
"args": ["-y", "@supabase/mcp-server-supabase@latest"],
"env": {
"SUPABASE_URL": "https://tu-proyecto.supabase.co",
"SUPABASE_SERVICE_ROLE_KEY": "tu-service-role-key"
}
}
}
}
Una vez que reinicias Claude Code con esta configuración, el agente tiene acceso a tu base de datos. Puedes pedirle que revise el schema, que ejecute una query, que busque errores en los logs.
Qué ocurre cuando Claude usa una herramienta MCP
Por defecto, Claude Code te muestra cada llamada MCP antes de ejecutarla. Verás algo como:
Tool call: filesystem.read_file
Arguments: { "path": "/src/components/UserCard.tsx" }
Puedes aprobarla, rechazarla o configurar permisos permanentes por servidor. El flujo de trabajo es transparente — no hay caja negra.
Esto conecta directamente con lo que explico en el post sobre Context Engineering para proyectos de IA: el contexto que tiene el agente determina la calidad de sus decisiones. MCP es una de las palancas más directas para darle al agente contexto real, no simulado.
El ecosistema MCP hoy
La adopción ha sido rápida. Hoy existen servidores MCP oficiales o comunitarios para:
- Supabase, PostgreSQL, SQLite
- GitHub, GitLab, Linear
- Notion, Confluence, Obsidian
- Slack, Discord
- AWS, Google Cloud
- Playwright (para automatizar navegadores)
- Docker
- Y decenas más
El registro de servidores MCP crece cada semana. Si la herramienta que necesitas no tiene servidor MCP todavía, puedes construir el tuyo — el SDK oficial de Anthropic para TypeScript y Python hace que crear un servidor MCP básico sea trabajo de pocas horas.
Por dónde empezar hoy
Si nunca has configurado un servidor MCP, el camino más corto es este:
- Abre Claude Code en un proyecto real tuyo.
- Crea un archivo
.mcp.jsonen la raíz con el servidor de filesystem apuntando a tu directorio de trabajo. - Reinicia Claude Code.
- Pídele que liste los archivos del proyecto, que lea un componente específico, que analice la estructura.
No necesitas construir nada. Solo configurar. En menos de 10 minutos tienes un agente que trabaja con el contexto real de tu proyecto en lugar de con lo que tú le describes.
Si todavía no tienes configurado el contexto base de tu proyecto, el post sobre cómo estructurar tu CLAUDE.md es el punto de partida — MCP y CLAUDE.md son complementarios, no alternativos.
El siguiente paso natural es conectar tu base de datos si usas Supabase, o GitHub si gestionas un repositorio con actividad. Cada servidor MCP que añades amplía lo que el agente puede hacer sin intervención tuya.
Y si quieres entender la arquitectura completa — no solo el protocolo MCP sino todo el sistema que lo rodea, de la spec al producto funcionando — eso es exactamente lo que cubrimos en el curso Construye con IA. Si quieres explorar esto con otros developers y ver proyectos reales con MCP en acción, en Dominicode Labs revisamos este tipo de proyectos regularmente.
FAQ
¿MCP es solo para Claude o funciona con otros LLMs?
MCP es un protocolo abierto — no es propietario de Anthropic en el sentido de que solo funcione con Claude. Otros clientes MCP compatibles pueden usar los mismos servidores. La apuesta de Anthropic fue precisamente crear un estándar que la industria pudiese adoptar, no una ventaja competitiva cerrada. Hoy el ecosistema está centrado en Claude Code y Claude Desktop, pero la adopción por parte de otros clientes está creciendo.
¿Es seguro darle acceso a Claude a mi base de datos o sistema de archivos?
Depende de cómo lo configures. El servidor MCP de filesystem solo puede acceder a las rutas que tú especifiques — no tiene acceso a toda tu máquina. Con Supabase, usas la service role key, que tiene permisos amplios, por lo que hay que ser cuidadoso con qué operaciones permites. Por defecto Claude Code te muestra cada llamada MCP antes de ejecutarla. La regla general: mínimo privilegio — dale al servidor MCP exactamente los permisos que necesita, no más.
¿Necesito saber TypeScript o Python para usar MCP?
Para usar servidores MCP existentes, no. Solo necesitas editar un archivo JSON de configuración y tener Node.js instalado (para los servidores que usan npx). Para construir tu propio servidor MCP, el SDK oficial de Anthropic está disponible en TypeScript y Python, y el punto de partida es sencillo — un servidor básico son menos de 50 líneas.
¿Cuál es la diferencia entre MCP y un plugin de ChatGPT?
Los plugins de ChatGPT fueron un intento propietario de conectar LLMs a herramientas externas, y OpenAI los deprecó en 2024. MCP es un protocolo abierto, no una feature de un producto específico. La diferencia práctica: un servidor MCP que construyas hoy puede ser usado por cualquier cliente MCP compatible mañana. Un plugin de ChatGPT solo funcionaba con ChatGPT, con las restricciones y cambios que OpenAI decidiera unilateralmente.
¿MCP reemplaza completamente el function calling tradicional?
No exactamente. Function calling sigue siendo el mecanismo subyacente — MCP lo usa internamente. Lo que MCP añade es la capa de estandarización: define cómo se describen las herramientas, cómo se comunica el cliente con el servidor, cómo se gestionan los errores. Es más una capa de protocolo sobre function calling que un reemplazo.
*Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.*
