Model Context Protocol resuelve un problema de interoperabilidad.

No vuelve inteligente a un agente. No decide qué tool debe ser confiable. No reemplaza tus APIs, tu modelo de permisos ni la lógica de tu aplicación.

Lo que hace es estandarizar una forma para que aplicaciones de IA descubran y usen tools, datos y prompts reutilizables externos.

Parece una diferencia pequeña. En la práctica importa porque, sin un protocolo compartido, cada aplicación termina construyendo adaptadores propios para cada sistema externo.

El modelo mental útil es:

MCP es una capa de interoperabilidad entre aplicaciones de IA y capacidades externas.

El problema que MCP intenta resolver

Imagina un agente que necesita acceso a:

  • GitHub;
  • documentación privada;
  • una base de datos;
  • APIs internas de billing;
  • un navegador;
  • un entorno local de desarrollo.

Puedes integrar cada sistema directamente.

Normalmente eso implica escribir lógica específica para conexión, schemas, autenticación, transporte, descubrimiento de capacidades y manejo de errores.

Después otro cliente de IA necesita lo mismo y repite buena parte del trabajo.

MCP crea un contrato común entre el host de IA y el proveedor de capacidades.

El proveedor implementa un MCP server. El host se conecta mediante un MCP client. El modelo puede descubrir las capacidades que el server expone.

La documentación oficial de MCP lo describe como un estándar abierto que conecta aplicaciones de IA con los sistemas donde viven tools y datos. Los servers pueden exponer tools, resources y prompts, y hosts compatibles pueden consumirlos.

Las tres primitivas más importantes

Tools

Las tools son operaciones invocables.

Ejemplos:

  • get_order(order_id);
  • create_ticket(...);
  • search_repository(...);
  • run_test_suite(...);
  • calculate_quote(...).

Una tool normalmente tiene nombre, descripción y entrada estructurada. El host puede descubrirla, el modelo puede decidir usarla y el server ejecuta la operación.

Resources

Los resources son datos o contenido que el cliente puede leer.

Ejemplos:

  • un archivo de configuración;
  • un documento;
  • un artifact de repositorio;
  • un registro de conocimiento;
  • un reporte generado.

Son útiles cuando la aplicación necesita contexto sin convertir toda lectura en una función orientada a acción.

Prompts

Los prompts son plantillas o patrones reutilizables que el server expone.

Permiten empaquetar instrucciones de dominio para que distintos hosts no tengan que recrear la misma lógica de interacción.

Estas primitivas separan tres ideas distintas: hacer algo, leer algo y reutilizar un patrón de interacción.

MCP no reemplaza function calling

Function calling y MCP operan en capas distintas.

Function calling es el mecanismo por el que un modelo selecciona una función y produce argumentos estructurados.

MCP estandariza cómo capacidades externas pueden publicarse, descubrirse, conectarse e invocarse entre clientes compatibles.

Una forma simple de verlo:

  • function calling define cómo un modelo llama una función;
  • MCP define un protocolo reutilizable para de dónde vienen esas funciones y otras capacidades relacionadas.

Una tool MCP puede terminar presentándose al modelo mediante el mecanismo normal de tool calling del host.

La documentación actual de OpenAI, por ejemplo, permite conectar modelos tanto a MCP servers remotos como a servers locales o privados mediante su infraestructura MCP.

MCP no reemplaza tus REST APIs

Un MCP server suele vivir encima de una API existente.

Si tu negocio ya expone:

POST /refunds

no tienes que reconstruir el sistema de pagos alrededor de MCP.

Puedes exponer una tool:

issue_refund(order_id, reason)

y hacer que el server use internamente la API existente.

La API sigue siendo la interfaz operacional. MCP se vuelve una capa de interoperabilidad orientada a clientes de IA.

Esto es importante porque tu API probablemente ya concentra:

  • reglas de negocio;
  • autorización;
  • validación;
  • idempotencia;
  • auditoría;
  • semántica transaccional.

MCP no debería duplicar esas responsabilidades.

MCP no reemplaza un agent framework

MCP no decide:

  • qué objetivo persigue el agente;
  • qué tool llamar primero;
  • si debe reintentar;
  • cuándo detenerse;
  • cómo manejar memoria;
  • cuándo pedir aprobación;
  • cómo coordinar múltiples agentes.

Esas son decisiones de orquestación.

Un agent framework puede consumir MCP servers como fuente de tools y contexto, pero MCP no es el reasoning loop.

Tener diez MCP servers no vuelve automáticamente más agentic a un sistema. Sólo significa que tiene diez proveedores de capacidades estandarizadas.

MCP no reemplaza RAG

RAG y MCP pueden trabajar juntos, pero resuelven problemas distintos.

RAG responde:

¿Qué evidencia debo recuperar y colocar en el contexto del modelo?

MCP responde:

¿Cómo conecta una aplicación de IA con un proveedor externo de forma estándar?

Un MCP server puede exponer una tool de búsqueda o un resource respaldado por un vector database.

Eso no significa que MCP defina chunking, embeddings, ranking, retrieval quality, citas o grounding.

Esas siguen siendo decisiones del sistema de retrieval.

Qué estandariza realmente MCP

El valor de un protocolo aparece en los límites que vuelve predecibles.

MCP ofrece convenciones comunes alrededor de:

  • descubrimiento de capacidades;
  • definiciones estructuradas de tools;
  • resources y prompts;
  • comunicación client/server;
  • transportes;
  • autorización;
  • errores y comportamiento del protocolo.

Los SDKs oficiales actuales soportan transportes como stdio para procesos locales y Streamable HTTP para conexiones remotas.

Eso permite usar la misma idea de server en distintos entornos: localmente desde una herramienta de programación, remotamente desde un producto hospedado o dentro de infraestructura empresarial.

Esa portabilidad es uno de sus beneficios principales.

Un ejemplo concreto

Imagina una empresa con un sistema interno de inventario.

El backend ya tiene APIs para:

  • buscar productos;
  • consultar stock;
  • crear reservas;
  • liberar reservas.

En lugar de integrar esas APIs por separado en cada aplicación de IA, la empresa crea un MCP server.

Expone:

  • search_products(query);
  • get_inventory(product_id);
  • reserve_inventory(product_id, quantity);
  • release_reservation(reservation_id).

Ahora hosts compatibles pueden descubrir esas capacidades mediante el mismo protocolo.

El MCP server no se convierte en la base de datos.

No se convierte en el sistema de autorización.

No decide si el agente puede reservar 10,000 unidades.

Proporciona una interfaz estandarizada hacia sistemas que ya existen.

La frontera de seguridad sigue siendo tu responsabilidad

Estandarizar la conectividad hace las integraciones más fáciles. También puede hacer más fácil construir integraciones inseguras.

Por eso importa el trust model.

La guía actual de OpenAI advierte explícitamente que servidores MCP remotos pueden recibir datos sensibles y que servidores maliciosos pueden introducir riesgos de prompt injection y exfiltración.

Controles importantes:

  • permitir sólo las tools necesarias;
  • exigir aprobación para operaciones sensibles;
  • mantener secretos fuera del contenido generado por el modelo;
  • usar OAuth o autorización equivalente;
  • validar los servers antes de conectarlos;
  • limitar los datos enviados a terceros;
  • conservar audit logs para acciones de alto impacto.

MCP te da un protocolo. No convierte a cada server en una entidad confiable.

El diseño de tools sigue importando

El modelo utiliza nombres, descripciones y schemas para decidir qué tool llamar.

Por eso el diseño de tools forma parte de la superficie de control del agente.

Una tool como:

manage_account(input)

es demasiado ambigua.

Varias tools estrechas suelen ser más fáciles de razonar:

  • get_account_status(account_id);
  • update_billing_address(account_id, address);
  • cancel_subscription(account_id, reason).

Los límites claros mejoran:

  • selección de tools;
  • diseño de permisos;
  • auditoría;
  • evaluación;
  • revisión humana.

MCP estandariza la exposición. El buen diseño sigue siendo responsabilidad de ingeniería.

Cuándo MCP aporta valor

No necesitas MCP para cada función interna.

Si una sola aplicación posee una sola tool y ningún otro cliente la usará, function calling directo puede ser más simple.

MCP gana valor cuando:

  • varios clientes de IA necesitan las mismas capacidades;
  • las capacidades deben ser portables entre hosts;
  • una organización quiere una frontera de integración reutilizable;
  • tools locales y remotas deben seguir una interfaz similar;
  • otros equipos o desarrolladores necesitan consumir el mismo contrato.

El protocolo reduce duplicación de integración.

No elimina la necesidad de criterio arquitectónico.

Tabla práctica

Pregunta Tool/function directa MCP
Una app y una integración privada Suele ser más simple Puede ser innecesario
Mismas tools para varios hosts Duplica integración Buen encaje
Descubrimiento estandarizado Custom Parte del protocolo
API REST existente Se llama directamente Un MCP server puede envolverla
Tool local de desarrollo Integración custom stdio encaja bien
Capacidad remota compartida Contrato HTTP custom Streamable HTTP encaja bien
¿Autorización sigue siendo necesaria? Sí Sí
¿Incluye planning/orquestación? No No

Qué no resuelve MCP

1. Corrección de tools

Una tool rota sigue rota aunque use un protocolo estándar.

2. Políticas de autorización

Todavía tienes que decidir qué usuario, agente u organización puede ejecutar cada operación.

3. Prompt injection

El contenido externo puede contener instrucciones maliciosas o conflictivas.

4. Confiabilidad del agente

Sigues necesitando evals, traces, retries, stop conditions y recovery.

5. Semántica de negocio

El protocolo no sabe si reembolsar, aprobar o eliminar algo es válido dentro de tu dominio.

6. Calidad de datos

MCP puede exponer datos. No vuelve confiable un dato viejo o incorrecto.

7. Observabilidad

Sigues necesitando logs, métricas, traces y registros de auditoría a nivel aplicación.

La regla de diseño

Usa MCP cuando necesites una frontera reutilizable de interoperabilidad entre aplicaciones de IA y capacidades externas.

Mantén lógica de negocio, permisos, fuentes de verdad y garantías operacionales dentro de los sistemas que ya las poseen.

Trata MCP como infraestructura.

No como inteligencia.

No como gobernanza.

No como seguridad por sí sola.

No como un agent framework.

Una buena integración MCP facilita conectar capacidades sin volver ambiguas sus responsabilidades.

Ese es el valor real del protocolo.

Fuentes