REST estandarizó cómo los servicios se comunican entre sí. GraphQL estandarizó cómo los clientes consultan datos. MCP está estandarizando cómo los modelos de IA interactúan con herramientas, datos y sistemas.

Si estás construyendo IA agentiva -- sistemas donde los modelos de lenguaje toman decisiones, invocan herramientas y afectan el estado -- estás construyendo una capa de integración. Esa capa es la parte más importante de tu arquitectura. No el modelo. No el prompt. La capa que se interpone entre las intenciones del modelo y el estado del mundo.

Hemos estado usando MCP en producción a través de múltiples sistemas. Este artículo trata sobre lo que aprendimos: por qué existe MCP, cómo se compara con lo que existía antes, dónde viven los límites de seguridad y los patrones que sobreviven al contacto con tráfico real.

I. El problema que MCP resuelve

Todos los equipos que construyen con modelos de IA chocan contra el mismo muro: la integración de herramientas.

El modelo necesita leer una base de datos. Necesita llamar a una API. Necesita acceder a archivos. Necesita buscar en una base de conocimiento. Cada integración es un trabajo artesanal: escribir un esquema JSON, conectar la autenticación, manejar errores, parsear respuestas, rezar para que el modelo lo invoque correctamente.

Multiplica esto por diez herramientas y tres modelos y tendrás un caos combinatorio. Cada modelo tiene su propio formato de llamada a funciones. Cada herramienta tiene su propio patrón de autenticación. Cada integración es a medida. Los tests son manuales. La auditoría es aspiracional.

Before MCP:


Model A ---custom--> Tool 1 (custom auth, custom schema)
  Model A ---custom--> Tool 2 (different auth, different schema)
  Model B ---custom--> Tool 1 (rewire everything)
  Model B ---custom--> Tool 2 (rewire everything again)



N models x M tools = N*M integrations

MCP colapsa esto. Define un protocolo estándar para que cualquier modelo pueda comunicarse con cualquier servidor de herramientas, y cualquier servidor de herramientas pueda servir a cualquier modelo. La matriz de integración se vuelve aditiva, no multiplicativa.

After MCP:


Model A --MCP--> Server 1 (tools: DB, files)
  Model A --MCP--> Server 2 (tools: API, search)
  Model B --MCP--> Server 1 (same protocol)
  Model B --MCP--> Server 2 (same protocol)



N models + M servers = N+M integrations

Este es el mismo cambio que REST trajo a la comunicación entre servicios. Un protocolo compartido que hace predecible el costo de integración.

II. El protocolo: qué define realmente MCP

MCP es un protocolo basado en JSON-RPC 2.0 con tres capacidades fundamentales:

Tools

Las herramientas son funciones que el modelo puede invocar. Cada herramienta tiene un nombre, una descripción (que el modelo lee para decidir cuándo usarla) y un JSON Schema para sus parámetros. El servidor registra las herramientas; el cliente (el runtime del modelo) las descubre y las presenta al modelo como acciones disponibles.

{
  "name": "query_database",
  "description": "Execute a read-only SQL query against the analytics database",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "SQL SELECT query (read-only)"
      }
    },
    "required": ["query"]
  }
}

El modelo ve este esquema y decide -- basándose en la solicitud del usuario y su propio razonamiento -- si invocar la herramienta y cómo hacerlo. El cliente MCP envía la invocación al servidor. El servidor la ejecuta y devuelve un resultado estructurado.

Resources

Los recursos son datos que el modelo puede leer. Archivos, registros de base de datos, respuestas de API, configuración -- cualquier cosa que el modelo pueda necesitar como contexto. Los recursos tienen URIs y pueden ser listados, leídos y suscritos para recibir actualizaciones.

Este es el «contexto» en Model Context Protocol. En lugar de meter todo en el system prompt, el modelo puede obtener lo que necesita, cuando lo necesita.

Prompts

Los prompts son plantillas reutilizables que los servidores pueden ofrecer a los clientes. Un servidor de base de datos podría ofrecer un prompt de «exploración de esquema». Un servidor de documentación podría ofrecer un prompt de «revisión de código». Son opcionales pero útiles para estandarizar flujos de trabajo comunes entre equipos.

La capa de transporte

MCP soporta dos transportes: stdio (para procesos locales) y HTTP con SSE (para servidores remotos). El transporte stdio es simple: lanzar un proceso, enviar JSON-RPC por stdin/stdout. El transporte HTTP añade capacidad de red con Server-Sent Events para streaming.

stdio transport (local):


Client --stdin/stdout--> MCP Server Process



HTTP transport (remote):



Client --HTTP POST--> MCP Server --SSE--> Client

La mayoría de las configuraciones de producción usan stdio para herramientas locales (sistema de archivos, base de datos) y HTTP para servicios remotos. El protocolo es el mismo; el transporte es un detalle de implementación.

III. MCP vs REST vs GraphQL: diferentes problemas, diferentes eras

Esta no es una comparación de «cuál es mejor». Estos protocolos resuelven problemas diferentes para consumidores diferentes.

REST estandarizó la comunicación entre servicios. El consumidor es un programador que escribe código contra una API conocida. La API está diseñada para comprensión humana: los endpoints tienen nombres, documentación y versionado. El consumidor sabe lo que quiere antes de hacer la solicitud.

GraphQL estandarizó las consultas de datos dirigidas por el cliente. El consumidor es un desarrollador frontend que necesita acceso flexible a un grafo de datos. La API está diseñada para composición de consultas: el cliente especifica exactamente qué datos necesita. El consumidor conoce el esquema y construye consultas contra él.

MCP estandariza la interacción modelo-herramienta. El consumidor es un modelo de lenguaje que descubre herramientas en tiempo de ejecución y decide cuál usar basándose en razonamiento en lenguaje natural. La API está diseñada para comprensión por máquinas: las descripciones de herramientas están escritas para que los modelos puedan entender cuándo y cómo usarlas.

Protocol   Consumer     Discovery      Selection
  -------------------------------------------------------
  REST       Programmer   Documentation  Code-time choice
  GraphQL    Frontend     Schema intro   Query composition
  MCP        LLM          Runtime list   Reasoning-based

La intuición clave: las herramientas MCP deben ser autodescriptivas de una manera que los modelos puedan razonar. Un endpoint REST llamado /api/v2/analytics/query está bien para un programador que leyó la documentación. Una herramienta MCP necesita una descripción como «Ejecutar una consulta SQL de solo lectura contra la base de datos de analytics. Usar cuando el usuario pregunte sobre métricas, patrones de uso o datos históricos.» La descripción es parte de la interfaz, no un comentario.

IV. Límites de seguridad: el servidor MCP como punto de control

Aquí es donde MCP demuestra su valor en producción. El servidor MCP no es solo un puente entre el modelo y las herramientas. Es un límite de seguridad.

Principio: el modelo no guarda secretos

El modelo nunca ve credenciales de base de datos, claves de API ni tokens de autenticación. El servidor MCP guarda los secretos. El modelo tiene los esquemas de herramientas. Cuando el modelo invoca una herramienta, el servidor autentica la solicitud, aplica las credenciales, ejecuta la acción y devuelve el resultado. El modelo ve la salida, no la fontanería.

{
  "mcpServers": {
    "database": {
      "command": "mcp-server-postgres",
      "args": ["--read-only", "--connection", "$DB_URL"],
      "env": { "DB_URL": "postgres://readonly:***@db.internal/analytics" }
    }
  }
}

La $DB_URL se resuelve del lado del servidor. El modelo nunca la ve.

Principio: acotar el acceso por servidor

Cada servidor MCP debería exponer el mínimo de herramientas necesarias para su propósito. Un servidor de reportes expone consultas de base de datos de solo lectura. Un servidor de archivos expone acceso de lectura a directorios específicos. Un servidor de publicación expone acceso de escritura a un CMS específico.

No construyas un servidor MCP que pueda hacer todo. Construye muchos servidores que puedan hacer cada uno una cosa bien. Este es el principio de mínimo privilegio aplicado al acceso de herramientas por IA.

Principio: auditar todo

Cada invocación de herramienta pasa por el servidor MCP. Eso lo convierte en el punto natural de auditoría. Registrar:

  • Marca temporal
  • Nombre de la herramienta y parámetros
  • Identidad del modelo/agente que llama
  • Contexto del usuario (quién desencadenó la tarea)
  • Resumen del resultado
  • Latencia y costo en tokens

Este registro de auditoría no es solo para depuración. Es para cumplimiento normativo. El EU AI Act exige registro y trazabilidad para sistemas de IA de alto riesgo. MCP te da el punto de control donde ese registro vive de forma natural.

Principio: limitar la tasa en el servidor

El modelo no sabe que es costoso. Un modelo en un bucle de reintento invocará felizmente una herramienta cincuenta veces. El servidor MCP debería aplicar límites de tasa por herramienta, por agente, por tarea. Cuando se alcanza el límite, devolver un error estructurado: «Límite de tasa excedido. Has usado 10 de 10 llamadas permitidas a query_database para esta tarea.»

El modelo puede razonar sobre esta retroalimentación y ajustar su enfoque. Esto no es un crash. Es una restricción dentro de la cual el agente puede operar.

V. Patrones de producción

Patrón 1: el analista de solo lectura

El patrón MCP de producción más común. Un modelo tiene acceso de solo lectura a bases de datos y archivos. Responde preguntas consultando datos, no modificando estado.

User: "What was our conversion rate last week?"
       |
  Agent --MCP--> database server (read-only)
       |         -> SELECT ... FROM events WHERE ...
       |
  Agent: "Last week's conversion rate was 3.2%, up from 2.8%."

Perfil de seguridad: bajo riesgo. El modelo no puede modificar datos. El peor caso es una consulta costosa, que el servidor limita por tasa.

Patrón 2: el escritor acotado

El modelo puede escribir en un sistema específico y acotado. Un sistema de gestión de contenidos. Un rastreador de tareas. Un pipeline de despliegue. El acceso de escritura está acotado a operaciones específicas con validación.

{
  "name": "create_draft",
  "description": "Create a new draft article in the CMS",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string", "maxLength": 200 },
      "body": { "type": "string", "maxLength": 50000 },
      "status": { "type": "string", "enum": ["draft"] }
    },
    "required": ["title", "body"]
  }
}

Nota: el campo status está restringido a "draft". El modelo no puede publicar directamente. Un humano revisa y publica. El esquema es la barrera de seguridad.

Patrón 3: el orquestador multi-servidor

Las tareas complejas requieren múltiples servidores MCP. El agente consulta una base de datos, lee documentación y actualiza un rastreador de tareas -- cada uno a través de un servidor diferente con permisos diferentes.

Agent --MCP--> database (read-only)
       --MCP--> documentation (read-only)
       --MCP--> task-tracker (scoped write)
       --MCP--> slack-notifier (scoped write)

Cada servidor es auditable de forma independiente. Cada servidor tiene sus propios límites de tasa y permisos. El agente orquesta; los servidores aplican las reglas.

Patrón 4: el servidor gateway

Para despliegues empresariales con muchas herramientas, un servidor MCP gateway agrega múltiples backends detrás de una interfaz única. El gateway maneja autenticación, enrutamiento y preocupaciones transversales (registro, limitación de tasa, circuit breaking).

Agent --MCP--> Gateway Server ---> Backend A
                                ---> Backend B
                                ---> Backend C

Esto añade una capa pero simplifica la configuración del cliente y centraliza la política de seguridad.

VI. Construir servidores MCP: notas prácticas

Mantener las descripciones honestas

La descripción de la herramienta es el campo más importante. Los modelos la usan para decidir cuándo invocar la herramienta. Una descripción vaga produce una selección incorrecta de herramientas. Una descripción que promete más de lo que la herramienta entrega produce errores en tiempo de ejecución.

Escribe las descripciones como si estuvieras explicando la herramienta a un colega competente que nunca ha visto tu código. Sé específico sobre lo que la herramienta hace, lo que no hace y cuándo debería usarse.

Validar inputs de forma estricta

El modelo alucinará parámetros. Enviará strings donde esperas números. Omitirá campos obligatorios. Inventará nombres de campos. Tu servidor debe validar cada input contra el esquema y devolver mensajes de error útiles.

Un buen mensaje de error: «El parámetro 'date_range' debe ser un objeto con campos string 'start' y 'end' en formato ISO 8601. Recibido: string.»

Un mal mensaje de error: «Input inválido.»

El modelo puede autocorregirse con buena retroalimentación. No puede autocorregirse con mala retroalimentación.

Devolver resultados estructurados

Los modelos razonan mejor sobre datos estructurados que sobre prosa. Devuelve objetos JSON con nombres de campo claros, no párrafos de texto.

{
  "result": {
    "rows_returned": 42,
    "data": [...],
    "query_time_ms": 23,
    "note": "Results limited to 100 rows per policy"
  }
}

Tratar errores como datos

Los errores de herramientas no son excepcionales en sistemas agentivos. Son normales. Una consulta que no devuelve resultados. Un límite de tasa que se alcanza. Un permiso que se deniega. Devuelve estos como respuestas de error estructuradas, no como excepciones que colapsan el agente.

VII. La ruta de adopción empresarial

Empezar con solo lectura

Toda adopción empresarial de MCP debería empezar con servidores de solo lectura. Conectar el modelo a bases de datos, documentación y sistemas de monitoreo. Permitir que los equipos construyan confianza en que el modelo usa las herramientas correctamente antes de conceder acceso de escritura.

Añadir acceso de escritura tras puertas de aprobación

Cuando el modo de solo lectura esté probado, añadir acceso de escritura acotado con aprobación human-in-the-loop. El modelo propone acciones; los humanos aprueban o rechazan. Rastrear tasas de aprobación, motivos de rechazo y tasas de error. Cuando la tasa de error sea consistentemente baja, considerar reducir la puerta de aprobación a revisión por muestreo.

Estandarizar entre equipos

El poder de MCP es el protocolo compartido. Si cada equipo construye su propia integración de herramientas, se pierde el beneficio de composabilidad. Publicar plantillas internas de servidores MCP. Definir convenciones de nomenclatura para herramientas. Establecer líneas base de seguridad para la configuración de servidores.

Monitorear patrones de uso de herramientas

Los servidores MCP generan telemetría rica: qué herramientas se invocan, con qué frecuencia, por qué agentes, con qué tasas de éxito. Estos datos son oro para entender cómo se está usando realmente la IA en tu organización -- y dónde tiene dificultades.

VIII. Lo que MCP no resuelve

MCP es un protocolo de integración. No resuelve:

  • Calidad del modelo. Un mal modelo con buenas herramientas sigue siendo un mal sistema.
  • Prompt engineering. MCP proporciona herramientas; aún necesitas instruir al modelo sobre cómo usarlas sabiamente.
  • Eval. MCP no te dice si el modelo está usando las herramientas correctamente. Necesitas harnesses de eval para eso.
  • Orquestación multi-modelo. MCP conecta un modelo con herramientas. Coordinar múltiples modelos es una preocupación de nivel superior.
  • Gobernanza de datos. MCP aplica el acceso a nivel de servidor, pero la decisión sobre a qué datos debería acceder el modelo es tuya.

MCP es un estándar de fontanería. Como REST, su valor está en lo que habilita, no en lo que hace por sí mismo.

IX. Por qué esto importa ahora

La industria de la IA está en el punto de inflexión de la integración. La curva de capacidad de los modelos ha superado a la infraestructura de integración. Los modelos pueden razonar sobre tareas complejas, planificar flujos de trabajo de múltiples pasos y usar herramientas de forma efectiva -- pero conectarlos a las herramientas que necesitan sigue siendo un esfuerzo manual, frágil y equipo por equipo.

MCP es el intento más creíble de estandarizar esta capa. No es el único intento -- OpenAI tiene function calling, Google tiene extensions, LangChain tiene abstracciones de herramientas. Pero MCP tiene tres ventajas: es agnóstico respecto al modelo, es open-source y define los límites de seguridad como una preocupación de primera clase.

Usamos MCP porque nos permite construir una vez y conectar cualquier modelo. Lo usamos porque la arquitectura de servidor-como-punto-de-control nos da las propiedades de auditoría y seguridad que necesitamos. Lo usamos porque es aburrido de la manera correcta -- un protocolo, no un framework; un estándar, no una opinión.

Los equipos que construyan buena infraestructura MCP ahora tendrán una ventaja compuesta. Cada nueva herramienta, cada nuevo modelo, cada nuevo caso de uso se conecta a la infraestructura existente en lugar de requerir una nueva integración. Esa es la promesa de los estándares. MCP la está cumpliendo.

Referencias

  1. Model Context Protocol. Specification. spec.modelcontextprotocol.io
  2. Anthropic. Introducing the Model Context Protocol. anthropic.com
  3. MCP. Official Server Implementations. github.com/modelcontextprotocol/servers
  4. JSON-RPC 2.0 Specification. jsonrpc.org
  5. Fielding, R. (2000). Architectural Styles and the Design of Network-Based Software Architectures. Doctoral dissertation, UC Irvine.
  6. GraphQL Foundation. GraphQL Specification. graphql.org
  7. European Parliament. EU AI Act -- Logging and Traceability Requirements. artificialintelligenceact.eu
  8. OWASP. LLM Top 10. owasp.org
  9. Anthropic. Tool Use Documentation. docs.anthropic.com
  10. OpenAI. Function Calling. platform.openai.com
  11. Google. Gemini Function Calling. ai.google.dev
  12. NIST. AI Risk Management Framework. nist.gov