MCP (Model Context Protocol): el estándar abierto que cambia cómo conectas IA a tus sistemas

Durante dos años cada vez que querías que un modelo de lenguaje accediera a tu base de datos, tu Jira, tu file system o tu API interna, tenías que construir una integración a la medida para cada modelo. La integración para GPT no servía para Claude, la de Claude no servía para Gemini, y cada actualización de la API rompía algo.

MCP (Model Context Protocol) resuelve eso. Es un estándar abierto, propuesto por Anthropic en 2024 y adoptado en 2025 por OpenAI, Google, Microsoft y la mayoría del ecosistema. Si tu empresa está construyendo asistentes o agentes con IA, entender MCP te ahorra meses de trabajo y te evita decisiones de arquitectura que después son dolorosas.

El problema que resuelve

Antes de MCP, la realidad era esta: cada proveedor de LLM tenía su propio mecanismo para invocar tools externas. OpenAI tenía function calling, Anthropic tenía tool use, Google tenía su propio formato. Si querías construir un asistente que diera acceso al mismo Jira a varios modelos, escribías el código tres veces.

A esto se sumaba el problema de la integración por sistema: cada LLM-aplicación implementaba a su manera la conexión a Postgres, a Slack, a tu repo de Git. No había nada reutilizable. La curva de soporte se volvía exponencial al crecer el número de modelos por número de sistemas.

MCP corta el problema en dos: define un protocolo estándar entre el cliente (la aplicación que usa el LLM) y el servidor (el sistema que expone capacidades). Cualquier LLM compatible con MCP habla con cualquier servidor MCP. Una vez expones tu sistema vía servidor MCP, está disponible para todos los modelos del ecosistema.

Componentes principales

MCP define tres piezas:

• Cliente MCP: la aplicación que usa el LLM (Claude Desktop, Cursor, tu propia app con SDK MCP).
• Servidor MCP: el sistema que expone capacidades (resources, tools, prompts) al cliente.
• Transporte: el canal por donde se comunican (stdio para procesos locales, HTTP+SSE o WebSocket para servidores remotos).

El servidor expone tres tipos de cosas:

1. Resources: datos que el modelo puede leer (archivos, registros de DB, documentos).
2. Tools: funciones que el modelo puede ejecutar (queries, llamadas a API, comandos).
3. Prompts: plantillas de prompt reutilizables que el cliente puede invocar.

El protocolo se basa en JSON-RPC 2.0, lo que lo hace simple de implementar en cualquier lenguaje.

Adopción en 2025

MCP pasó de propuesta de Anthropic a estándar de facto. Los hitos:

• Claude Desktop y Claude Code lo soportan nativo.
• OpenAI anunció soporte en su SDK y en la Responses API.
• Microsoft lo integró en GitHub Copilot, Visual Studio Code y Copilot Studio.
• Google anunció soporte en Vertex AI y herramientas de desarrollo.
• Cursor, Zed, Continue y otros editores con IA lo adoptaron.
• Cientos de servidores MCP públicos para Postgres, GitHub, Notion, Slack, Linear, Jira, Google Drive, Sentry y más.

El ecosistema se parece al de los language servers (LSP) hace una década: una vez aceptado el estándar, la velocidad de adopción y de creación de servidores explota.

Casos típicos para empresas

Donde vemos a empresas mexicanas usándolo:

1. Acceso a base de datos interna

Servidor MCP que expone tu base de datos de forma controlada al asistente. El modelo puede consultar, no modificar (o solo modificar tablas específicas), con autenticación y log de cada query.

2. Integración con sistema de tickets

Servidor MCP que conecta a Jira, Linear o ServiceNow. El asistente puede crear, leer y actualizar tickets desde la conversación con el usuario, sin cambiar de contexto.

3. Documentación interna

Servidor MCP que expone Confluence, Notion o tu wiki interno con búsqueda semántica. El modelo recupera el contexto relevante automáticamente.

4. APIs internas

Servidor MCP que expone una colección controlada de endpoints internos. Más simple que dar al modelo acceso libre a curl, más seguro que generar código de cliente cada vez.

5. Sistemas legacy

Servidor MCP que envuelve un sistema viejo (SAP, ERP propietario, mainframe) y le da una interfaz moderna. El modelo no necesita entender el legacy; el servidor MCP traduce.

Tutorial mínimo: servidor MCP en Python

Para que veas lo simple que puede ser, este es un servidor MCP que expone una tool para consultar una base de Postgres:

from mcp.server.fastmcp import FastMCP
import psycopg2

mcp = FastMCP("postgres-mcp")

@mcp.tool()
def query_clientes(buscar: str) -> list:
    """Busca clientes por nombre o email."""
    conn = psycopg2.connect("dbname=miapp user=...")
    cur = conn.cursor()
    cur.execute(
        "SELECT id, nombre, email FROM clientes "
        "WHERE nombre ILIKE %s OR email ILIKE %s LIMIT 20",
        (f"%{buscar}%", f"%{buscar}%")
    )
    rows = cur.fetchall()
    conn.close()
    return [{"id": r[0], "nombre": r[1], "email": r[2]} for r in rows]

if __name__ == "__main__":
    mcp.run()

Eso es funcional. Conectado a Claude Desktop o a tu cliente preferido, el modelo ya puede llamar a la tool con un prompt como "busca el cliente con email rodriguez".

En menos de 50 líneas tienes un servidor productivo. La complejidad que sigue es manejo de credenciales, autorización por usuario, paginación, observabilidad y seguridad.

Riesgos de seguridad

MCP no resuelve mágicamente la seguridad. Al contrario, abre superficie nueva si no se maneja con cuidado. Los riesgos a tener en mente:

• Tool poisoning: un servidor MCP malicioso puede exponer tools cuya descripción manipule el comportamiento del modelo.
• Confused deputy: si el servidor corre con permisos amplios, el modelo puede ejecutar acciones que el usuario no autorizó explícitamente.
• Exfiltración de datos desde un servidor comprometido hacia destinos externos.
• Prompt injection a través de resources que contienen instrucciones ocultas dentro del contexto.

Mitigaciones que recomendamos

• Catálogo aprobado de servidores MCP, no instalación libre por usuario.
• Sandboxing de cada servidor en proceso o contenedor separado.
• Mínimo privilegio: cada servidor solo expone lo necesario.
• Auditoría completa de cada tool call (quién, qué, cuándo, resultado).
• Sanitización de resources que vienen de fuentes externas.
• Rotación de credenciales del servidor, no compartir con el cliente.
• Revisión de seguridad por servidor antes de uso en producción, igual que cualquier integración crítica.

Por dónde empezar

Si tu empresa quiere adoptar MCP, el orden que recomendamos:

1. Probar con servidores oficiales (filesystem, GitHub, Postgres) en entorno aislado para entender el flujo.
2. Construir un servidor interno para un caso de bajo riesgo (consulta de catálogo, búsqueda en wiki).
3. Estandarizar autenticación y observabilidad antes de escalar.
4. Definir gobernanza: quién puede crear servidores, quién aprueba, quién audita.
5. Escalar a casos críticos (escritura, acciones en sistemas de producción) con human-in-the-loop al inicio.

MCP no es la próxima moda; es el plomería estándar para los próximos años. Las empresas que lo adopten temprano van a tener arquitecturas más limpias y agentes más capaces que las que sigan reinventando integraciones a la medida.

---

¿Quieres conectar IA con tus sistemas vía MCP? Te ayudamos. En ALCA construimos servidores MCP a la medida de tu stack y tu modelo de seguridad. Agenda 30 minutos con nuestro equipo.