Confesión de un escéptico convertido
Cuando Anthropic anunció el Model Context Protocol (MCP) en noviembre de 2024, mi primera reacción fue: “Ah, otro protocolo más que promete resolver todos los problemas de integración”. Como DevOps Manager que ha visto nacer y morir docenas de “estándares universales”, tengo razones para ser escéptico.
Pero después de varios meses viendo cómo MCP se ha adoptado masivamente - OpenAI lo integró en marzo 2025, Google DeepMind en abril - decidí investigar más allá del hype. Y tengo que admitir algo: estaba equivocado.
¿Qué es MCP? (La versión sin marketing)
MCP es, en esencia, “USB para integraciones de IA”. Antes de USB, cada periférico necesitaba su propio puerto y drivers. Con las integraciones de IA pasa lo mismo: cada herramienta necesita su propio conector personalizado.
El problema es matemático: M aplicaciones de IA × N fuentes de datos = M×N integraciones. MCP lo convierte en M+N, donde:
- M clientes MCP (uno por aplicación de IA)
- N servidores MCP (uno por fuente de datos)
// Antes: pesadilla de integraciones
const integrations = [
'claude-slack', 'claude-github', 'claude-postgres',
'chatgpt-slack', 'chatgpt-github', 'chatgpt-postgres',
'custom-agent-slack', 'custom-agent-github', 'custom-agent-postgres'
];
// Con MCP: un protocolo estándar
const mcpServers = ['slack-mcp', 'github-mcp', 'postgres-mcp'];
const mcpClients = ['claude-mcp', 'chatgpt-mcp', 'custom-agent-mcp'];
Mis razones iniciales para ser escéptico
1. “Es solo otro estándar más”
Llevamos décadas viendo “estándares universales” que mueren en el olvido. CORBA, SOAP, REST, GraphQL… cada uno prometía ser el definitivo.
2. “¿Realmente necesitamos esto?”
Con APIs REST y GraphQL funcionando bien, ¿por qué complicarse con otro protocolo? JSON-RPC parece overkill.
3. “La adopción será lenta”
Los estándares nuevos tardan años en adoptarse. ¿Quién va a construir servidores MCP sin clientes? ¿Quién va a integrar clientes sin servidores?
4. “Seguridad y complejidad”
Dar acceso a IA a sistemas internos, bases de datos, filesystems… ¿qué podría salir mal?
Por qué cambié de opinión
1. Antropic hizo los deberes
No lanzaron MCP solo como especificación. Llegó con:
- Cliente funcional: Claude Desktop
- Servidores de referencia: GitHub, Slack, PostgreSQL, Puppeteer, Google Drive
- SDKs completos: Python, TypeScript, Java, Kotlin, C#
- Tooling: MCP Inspector para debugging
Dogfooding desde el día uno. Antropic mismo usa MCP en producción.
2. Adopción explosiva
En menos de un año:
- OpenAI integró MCP en ChatGPT Desktop y Agents SDK
- Google DeepMind anunció soporte en Gemini
- Atlassian lanzó Remote MCP Server para Jira/Confluence
- Zed, Replit, Sourcegraph integraron MCP
- Miles de servidores comunitarios en GitHub
3. Casos de uso reales
No es solo hype teórico. Veo equipos usando MCP para:
- Acceso a datos internos desde Claude Desktop
- Integración de IDEs con contexto empresarial
- Automatización de workflows con acceso a múltiples sistemas
- Análisis de datos con acceso directo a bases de datos
4. Arquitectura bien pensada
# Arquitectura MCP simplificada
Host (Claude Desktop):
├── Client MCP
└── Conexiones a Servers MCP
├── GitHub MCP Server
├── Slack MCP Server
└── PostgreSQL MCP Server
Cada servidor es un proceso separado. Aislamiento de seguridad, facilidad de debugging, escalabilidad horizontal.
Lo que me convenció técnicamente
Primitivas bien definidas
MCP no es un protocolo monolítico. Define primitivas claras:
- Tools: Funciones que la IA puede ejecutar
- Resources: Datos que la IA puede leer
- Prompts: Plantillas predefinidas para guiar la IA
- Roots: Puntos de entrada al filesystem
- Sampling: Mecanismo para multi-step reasoning
JSON-RPC con WebSockets
No reinventaron la rueda. JSON-RPC es estándar, probado, simple. WebSockets para comunicación bidireccional. Nada revolucionario, pero funciona.
Autenticación y permisos
OAuth integrado, respeto a permisos existentes, control granular de acceso. Seguridad por diseño.
Casos de uso que realmente funcionan
1. Desarrollo con contexto empresarial
# Servidor MCP para acceso a Jira
npx @atlassian/mcp-server-jira
Claude Desktop ahora puede acceder a tus tickets de Jira, entender el contexto del proyecto, sugerir fixes basados en histórico de bugs.
2. Análisis de datos sin fricción
# Servidor MCP para PostgreSQL
mcp_server = PostgreSQLMCPServer(connection_string)
Pregunta a Claude: "¿Cuáles son los usuarios más activos en la última semana?" y obtén SQL + análisis.
3. Automatización de workflows
Con acceso a GitHub + Slack + Jira, Claude puede:
- Crear PRs basados en tickets de Jira
- Notificar en Slack cuando hay deployments
- Analizar métricas de performance
Docker + MCP = Combinación perfecta
Lo que más me gusta es la integración con Docker. Cada servidor MCP es un container:
# docker-compose.yml
services:
mcp-github:
image: mcp/github-server
environment:
- GITHUB_TOKEN=${GITHUB_TOKEN}
mcp-postgres:
image: mcp/postgres-server
environment:
- DATABASE_URL=${DATABASE_URL}
Distribución consistente, aislamiento de dependencias, escalabilidad. Todo lo que necesitas para producción.
Remote MCP: El siguiente nivel
Atlassian lanzó Remote MCP Servers - servidores MCP que corren en la nube, no localmente. Esto resuelve:
- Problemas de configuración (no necesitas instalar nada)
- Seguridad centralizada (OAuth + permisos corporativos)
- Escalabilidad (Cloudflare Workers + edge computing)
Mis preocupaciones restantes
1. Seguridad
En abril 2025, investigadores de seguridad encontraron vulnerabilidades en MCP:
- Prompt injection en herramientas
- Exfiltración de archivos combinando tools
- Suplantación de herramientas confiables
Esto es serio. Necesitamos mejores prácticas de seguridad antes de usar MCP en producción.
2. Complejidad operacional
Gestionar múltiples servidores MCP, debugging de conexiones, manejo de errores… puede volverse complejo rápido.
3. Vendor lock-in sutil
Aunque MCP es open source, los mejores servidores están siendo desarrollados por empresas grandes. ¿Qué pasa si Anthropic decide cambiar de dirección?
¿Por qué MCP va a triunfar?
1. Timing perfecto
Llegó justo cuando necesitamos integrar IA con sistemas existentes. No es demasiado temprano ni demasiado tarde.
2. Adopción de gigantes
OpenAI, Google, Anthropic, Atlassian… cuando los grandes players adoptan un estándar, usualmente funciona.
3. Desarrollo comunitario
Miles de desarrolladores ya contribuyendo servidores MCP. El ecosistema está creciendo orgánicamente.
4. Casos de uso claros
No es una solución buscando un problema. Resuelve pain points reales de integración.
Mi recomendación pragmática
Para escépticos como yo: Probadlo en un proyecto pequeño. Instala Claude Desktop, conecta un servidor MCP de GitHub o Slack, y vedlo por vosotros mismos.
Para equipos de desarrollo: Empezad con servidores MCP para vuestros sistemas internos. Documentación, bases de datos, herramientas de monitoring.
Para empresas: Vigilad la evolución de Remote MCP Servers. Atlassian está marcando el camino, pero vendrán más.
Conclusión: Del escepticismo a la confianza pragmática
MCP no es perfecto. Tiene problemas de seguridad, complejidad operacional, y el riesgo habitual de cualquier tecnología nueva. Pero funciona.
Lo que me convenció no fueron las promesas, sino ver adopción real por parte de empresas serias, resolviendo problemas reales, con código abierto y transparente.
Como escéptico que soy, seguiré vigilando de cerca. Pero también empezaré a experimentar. En un mundo donde la IA necesita acceso a datos empresariales, MCP parece ser la mejor apuesta que tenemos.
¿Qué opináis los escépticos? ¿Habéis probado MCP? ¿Creéis que va a ser otro estándar que muere en el olvido, o realmente tiene potencial?
Mi consejo: mantened el escepticismo saludable, pero no os cerréis a experimentar. A veces los estándares que funcionan son los que menos te esperabas.
PD: Si decidís probarlo, empezad con el MCP GitHub server. Es fácil de configurar y los casos de uso son obvios.
Comentarios