Model Context Protocol (MCP): El puente entre tus datos y los modelos de IA
¿Por qué debe importarte (como Arquitecto de Soluciones)?
Acceso controlado a datos
Evita hardcodear claves y el uso de proxies frágiles. Los permisos se definen explícitamente por recurso y método.
Estándar abierto
Independencia de proveedor y menor acoplamiento. Facilita la gobernanza multi–LLM y el versionado de integraciones.
Plugins seguros
Cada integración (API, BD, servicio) vive como un servidor MCP con capacidades y límites claros.
Escalabilidad y auditoría
Multiplica fuentes de contexto sin caídas de seguridad. Todo queda trazado: quién usó qué y para qué.
Arquitectura mínima de MCP
MCP define dos piezas:
- Servidor MCP: expone recursos del dominio (APIs, consultas a BD, archivos).
- Cliente MCP: el agente o LLM que invoca métodos de esos recursos.
La comunicación suele implementarse con JSON‑RPC sobre WebSocket, permitiendo llamadas tipadas y respuestas estructuradas.
Traducción #TeLoDijoElBuga: el LLM deja de “scrapear” cosas y pasa a conversar con servicios bien definidos.
Ejemplo 1: Consultar clientes del CRM sin exponer la base de datos
Objetivo: el LLM pide “nombres y correos de clientes activos” y el servidor MCP entrega justo eso. Nada más.
Manifiesto del servidor MCP (conceptual)
{
"name": "crm-server",
"version": "1.0",
"resources": [
{
"name": "customers",
"description": "Lista de clientes activos",
"methods": [
{
"name": "getCustomers",
"description": "Obtiene todos los clientes",
"params": [],
"returns": ["id", "nombre", "email"]
}
]
}
]
}
Flujo de llamada
// Request del cliente MCP
{
"jsonrpc": "2.0",
"id": 1,
"method": "customers.getCustomers",
"params": {}
}
// Respuesta del servidor MCP
{
"jsonrpc": "2.0",
"id": 1,
"result": [
{ "id": 1, "nombre": "Ana Pérez", "email": "ana@example.com" },
{ "id": 2, "nombre": "Carlos Gómez", "email": "carlos@example.com" }
]
}
Ejemplo 2: Clima por ciudad vía una API encapsulada
Queremos contestar: “¿Cuál es la temperatura en Lima?” sin revelar la API real.
{
"name": "weather-server",
"resources": [
{
"name": "weather",
"methods": [
{
"name": "getWeather",
"params": ["city"],
"returns": ["temperature", "description"]
}
]
}
]
}
// Llamada
{
"jsonrpc": "2.0",
"id": 7,
"method": "weather.getWeather",
"params": {"city": "Lima"}
}
// Respuesta
{
"jsonrpc": "2.0",
"id": 7,
"result": {"temperature": 26, "description": "cielo despejado"}
}
La política de acceso del servidor MCP decide qué puede pedirse y qué se devuelve.
¿Dónde encaja MCP en tu plataforma?
- Con API Gateway: MCP puede enrutar a APIs internas/externas, heredando rate‑limits y autenticación.
- Con Service Mesh: observabilidad, mTLS y control de tráfico para los servidores MCP.
- En OpenShift: despliega servidores MCP como microservicios; configura RBAC, secretos y pipelines.
Patrón recomendado
- Un servidor MCP por dominio (Ventas, Finanzas, RRHH).
- Permisos mínimos por método; auditoría central.
- Contratos versionados y pruebas contractuales (CD/CI).
Checklist #TeLoDijoElBuga para producción
- Define capacidades por recurso y documenta sus params/returns.
- Aplica principio de mínimo privilegio a nivel de método.
- Registra trazas de uso (quién, qué, cuándo, propósito).
- Incluye tests de contrato y límites de cuota.
- Versiona el contrato MCP como cualquier API.