GenAI Applications10 min de lectura•2 de febrero de 2026

Arquitectura, implementación y uso estratégico del Model Context Protocol (MCP)

Aprende cómo MCP estandariza el acceso a contexto y herramientas, desde primitivas del protocolo hasta despliegue seguro en Claude, Zed y servidores propios.

Escrito porLuis LapoFundador de Data Systems Academy. Enfocado en sistemas de datos en producción y ML engineering.

Etiquetas

El problema de interoperabilidad en la IA moderna

Los LLMs son excelentes para razonar y generar texto, pero siguen aislados operativamente. Claude, GPT-4 o Llama pueden explicar un diagrama, pero no pueden consultar tu inventario en tiempo real ni leer un repositorio privado sin integraciones a medida. Ese aislamiento crea un costo oculto que escala con cada nueva fuente de datos.

Cada conexión modelo-herramienta implica su propia autenticación, manejo de errores y transformación de datos. Si una empresa usa tres asistentes y necesita conectarlos a cuatro fuentes, termina con 12 conectores distintos. Esa complejidad N x M frena la innovación y aumenta la deuda técnica.

El Model Context Protocol (MCP) reduce esa fragmentación convirtiendo integraciones en infraestructura reutilizable. En lugar de construir un conector por asistente, se crea un servidor MCP por fuente de datos o herramienta y cualquier cliente compatible lo puede consumir. Es el equivalente lógico a un puerto USB-C para contexto de IA.

MCP en una frase

MCP es un protocolo abierto, basado en JSON-RPC, que estandariza cómo los clientes de IA descubren, leen y ejecutan contexto mediante recursos, herramientas, prompts y sampling.

Esa definición es clave porque habilita el paso de “chat y copiar/pegar” a “sistemas que pueden actuar de forma segura”. Con MCP, los modelos obtienen ojos y manos: leen archivos, consultan bases de datos y ejecutan tareas a través de interfaces controladas.

Arquitectura: Host, Cliente y Servidor

MCP es cliente-servidor, pero con roles claros:

Host: Aplicación de usuario (Claude Desktop, Zed, Cursor). Controla la sesión, la autenticación y el consentimiento. Decide cómo presentar herramientas y datos al LLM.
Cliente: Implementación del protocolo dentro del host. Se conecta a múltiples servidores y agrega capacidades en un solo set de herramientas.
Servidor: Proceso ligero que expone una funcionalidad específica (filesystem, Git, Slack, Postgres). Opera aislado y recibe solo el contexto necesario.

Esta separación favorece seguridad y modularidad. El host gobierna. Los servidores se mantienen pequeños y composables. El cliente agrega todo para el modelo.

Transportes: stdio, SSE (legacy) y Streamable HTTP

MCP es agnóstico al transporte, pero tres modos son los más comunes.

Stdio (local, más seguro)

El host inicia el servidor como subproceso local y se comunica por stdin/stdout. Es el modo más seguro y con menor latencia, ya que no abre puertos de red. El límite es que no escala a entornos distribuidos.

Nota operativa: nunca escribir logs en stdout. Usar stderr, porque stdout está reservado para JSON-RPC.

SSE sobre HTTP (legacy)

SSE usa un canal de lectura persistente y POSTs para escritura. Funciona, pero requiere dos canales y complica la bidireccionalidad avanzada. Hoy se considera modo de compatibilidad.

Streamable HTTP (preferido para remoto)

Streamable HTTP utiliza un solo endpoint con streaming bidireccional. Simplifica despliegues, mejora resiliencia de red y reduce la complejidad del cliente. Las librerías modernas lo adoptan por defecto.

JSON-RPC 2.0: contrato de mensajes

MCP usa JSON-RPC 2.0 para solicitudes, respuestas y notificaciones. La estructura explícita reduce ambigüedad y elimina integraciones basadas en texto libre.

Ejemplo: tools/call

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "obtener_clima",
    "arguments": {
      "ciudad": "Santiago",
      "pais": "CL"
    }
  }
}

Respuesta

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": "Cielo despejado, 26C",
    "isError": false
  }
}

Como las herramientas publican su esquema, el modelo puede llamar funciones con parámetros válidos sin prompts complejos.

Primitivas MCP: recursos, herramientas, prompts, sampling

MCP se apoya en cuatro primitivas que cubren casi todos los flujos de contexto.

Recursos (contexto pasivo)

Los recursos son datos de solo lectura, identificados por URIs. Por ejemplo file:///logs/system.log o postgres://db/tables/orders/schema. También existen plantillas como postgres://db/tables/{tabla}/schema para acceder a datos parametrizados. Los clientes pueden suscribirse y recibir notificaciones cuando cambian.

Herramientas (acciones y consultas)

Las herramientas son funciones ejecutables: leer, escribir, consultar, crear. Se publican con esquemas JSON para que el LLM conozca los argumentos. Los errores de ejecución se devuelven con isError: true para permitir autocorrección.

Prompts (flujos guiados)

Los prompts son flujos definidos por el servidor que aparecen como comandos (slash commands). Empaquetan contexto e instrucciones para casos recurrentes, como “Generar mensaje de commit” o “Resumir archivo”.

Sampling (el servidor solicita al modelo)

Sampling invierte el control: el servidor pide al host que genere una respuesta. Un ejemplo típico: el servidor lee un documento, solicita al modelo un resumen, y luego guarda el resultado en la base de datos. El host suele pedir confirmación al usuario.

Construir un servidor con FastMCP

FastMCP en Python permite crear servidores con decoradores y esquemas automáticos.

from fastmcp import FastMCP

mcp = FastMCP("FinanceOps")

@mcp.tool()
def interes_compuesto(capital: float, tasa: float, anos: int) -> str:
    """Calcula interes compuesto para una inversion simple."""
    total = capital * ((1 + tasa) ** anos)
    return f"Total despues de {anos} anos: ${total:.2f}"

@mcp.resource("finance://rates/{pais}")
def tasa_referencia(pais: str) -> str:
    tasas = {"US": "5.25%", "EU": "4.50%", "CL": "7.25%"}
    return tasas.get(pais, "Tasa no disponible")

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

Buenas prácticas:

Logs por stderr para no romper el stream de stdio.
Dependencias controladas y rutas absolutas al runtime de Python.
Servidores pequeños y de propósito único.

Conectar servidores a clientes

Claude Desktop

Claude Desktop usa un JSON para declarar servidores MCP. Usa rutas absolutas y variables de entorno para secretos.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "<token>"
      }
    },
    "financeops": {
      "command": "/Users/you/finance/.venv/bin/python",
      "args": ["/Users/you/finance/server.py"],
      "env": {
        "DB_URL": "postgres://user:pass@localhost:5432/db"
      }
    }
  }
}

Zed Editor

Zed soporta MCP con context_servers en settings.

{
  "context_servers": {
    "docker-server": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "mcp/server-image"],
      "env": {}
    }
  }
}

Docker MCP Toolkit

Docker Desktop ofrece un toolkit para correr servidores MCP en contenedores y conectarlos a Claude sin gestionar dependencias locales. Es útil para equipos que quieren entornos reproducibles y aislados.

Seguridad y gobernanza

MCP habilita más poder, pero exige más control.

Human-in-the-loop: el host pide aprobación para acciones sensibles.
Mínimo privilegio: el servidor valida permisos aunque la solicitud venga del LLM.
Riesgo de confused deputy: un documento malicioso puede inducir acciones. La verificación en el servidor es obligatoria.
OAuth en remoto: las especificaciones modernas recomiendan OAuth 2.1 en lugar de API keys estáticas.

Gobernanza no es opcional: es lo que convierte un agente útil en un sistema seguro.

Errores comunes al adoptar MCP

Al iniciar, es fácil caer en patrones que limitan el valor del protocolo:

Exponer demasiado contexto: enviar tablas completas o repos enteros aumenta costos y ruido. Filtra y pagina.
Mezclar lecturas y escrituras críticas: pone en riesgo operaciones sensibles. Separa herramientas por nivel de riesgo.
No versionar herramientas: cambios en parámetros rompen flujos existentes. Trata las herramientas como APIs.
Olvidar el UX del host: el modelo puede llamar herramientas, pero el usuario debe entender qué ocurrió y por qué.
No medir impacto: sin métricas de uso, latencia y errores es imposible mejorar la experiencia.

Corregir estos puntos temprano evita que MCP se convierta en otra capa difícil de operar.

Adopción estratégica: por dónde empezar

Si estás comenzando con MCP, inicia con un servidor de alto impacto y bajo riesgo:

Fuente de solo lectura (Postgres, warehouse, documentación).
Herramientas de bajo riesgo (búsqueda, resumen, extracción de metadatos).
Un solo host (Claude Desktop o Zed) para validar flujos.

Cuando haya tracción, crea un catálogo interno de servidores MCP y estandariza despliegues. El beneficio principal es la portabilidad: puedes cambiar de modelo o host sin reescribir integraciones.

Para priorizar, calcula el ROI con dos métricas simples: tiempo ahorrado por consulta y número de flujos repetitivos eliminados. Si un servidor reduce minutos por tarea en un equipo completo, el impacto se nota rápido.

Dónde encaja MCP en la arquitectura

MCP no reemplaza APIs ni límites de servicio. Es una capa de contexto que permite exponer sistemas existentes a hosts de IA de forma estandarizada. La regla general: la lógica de negocio sigue en tus servicios, y MCP solo expone el mínimo contexto y las acciones necesarias.

Patrones recomendados:

Separar lectura y escritura: un servidor para datos de solo lectura y otro para acciones. Así puedes bloquear herramientas destructivas sin frenar consultas seguras.
Servidores por dominio: tickets, incidentes, analítica, repos. La propiedad y auditoría quedan claras.
Contexto filtrado: evita enviar tablas completas. Agrega filtros y resúmenes en el servidor para enviar solo lo necesario.

Matriz simple de decisión:

Patrón Beneficio Riesgo Solo lectura Rápida adopción, bajo riesgo Menor automatización Lectura + escritura Acciones seguras y controladas Más servidores Un servidor por dominio Propiedad clara Overhead de despliegue

Si ya tienes APIs internas, MCP puede envolverlas sin duplicar lógica. Así agregas acceso de IA sin replatforming.

Checklist operativo para producción

Antes de usar MCP en flujos productivos, trata los servidores como servicios internos:

Autenticación y autorización: valida permisos del usuario en el servidor, no solo en el host.
Manejo de secretos: usa variables de entorno o secret manager, nunca hardcode.
Rate limits y timeouts: protege sistemas upstream.
Observabilidad: registra uso de herramientas, latencia y errores.
Caching y paginación: limita payloads y reduce carga.
Fallbacks claros: devuelve errores accionables para que el modelo reintente.

MCP reduce complejidad de integración, pero no reemplaza la disciplina operativa.

Conclusión

MCP no es una API más: es una capa de interoperabilidad que reorganiza la integración de IA en torno a contratos explícitos y servidores composables. Reduce el problema N x M a un modelo uno-a-muchos y habilita agentes que pueden leer, razonar y actuar sin pegamento frágil.

Para equipos que construyen IA en producción, MCP es el camino más práctico para pasar de “chat inteligente” a “inteligencia operativa”. Adopta temprano, mantén servidores pequeños y prioriza gobernanza. El resultado es una capa de contexto durable que evoluciona sin reingeniería constante.