Saltar al contenido
Todos los artículos
Fundamentos de IA

Protocolo de Contexto de Modelo (MCP)

El estándar universal que Sentina utiliza para conectar modelos de IA con herramientas, bases de datos y APIs empresariales. Qué es, cómo funciona, por qué todos los proveedores lo adoptaron y cómo implementarlo en tu negocio.

Rodrigo Cano

Rodrigo Cano

Sentina

18 de agosto de 202611 min de lectura
Protocolo de Contexto de Modelo (MCP)

El problema de integración M x N

Antes de MCP, cada desarrollador construía integraciones propietarias a la medida para cada herramienta. Si tenías 3 aplicaciones de IA y querías conectarlas a 3 herramientas (Slack, GitHub, Postgres), necesitabas 9 integraciones personalizadas. ¿Una herramienta más? 3 integraciones extra. ¿Otra app de IA? 4 integraciones más.

EscenarioIntegraciones necesarias
Antes de MCP (M × N conectores propietarios)3 aplicaciones × 3 herramientas = 9 integraciones. Cada una propietaria.
Con MCP (M + N conexiones estándar)3 clientes + 3 servidores = 6 implementaciones. Todas interoperables.

La analogía del puerto USB

Piensa en MCP como el estándar USB. Antes del USB, cada periférico requería un conector y controlador propietario. Con el USB, cualquier dispositivo funciona con cualquier computadora mediante un puerto universal. MCP logra lo mismo para la IA: cualquier aplicación puede invocar cualquier herramienta mediante un protocolo universal. Construyes el servidor una vez y lo usas en todas partes.

Qué es realmente MCP

MCP (Model Context Protocol) es un protocolo abierto creado por Anthropic y anunciado en noviembre de 2024. Estandariza cómo las aplicaciones de IA descubren, se conectan y utilizan herramientas y fuentes de datos externas. No es un producto ni un framework: es una especificación abierta que cualquiera puede implementar.

El protocolo se basa en JSON-RPC 2.0, un formato ligero de solicitud/respuesta. Todos los mensajes siguen el mismo patrón estructurado: el cliente envía una solicitud JSON con nombre de método y parámetros, y el servidor responde con el resultado o error.

MCP expone tres primitivas centrales, cada una controlada por una parte del sistema:

Herramientas

Acciones que el LLM puede invocar (consultar una base de datos, llamar a una API, enviar un mensaje o leer un archivo). El modelo decide cuándo y cómo ejecutarlas. Cada herramienta cuenta con nombre, descripción y un esquema JSON para sus parámetros.

Recursos

Datos contextuales de solo lectura identificados por URIs (archivos, esquemas de bases de datos, configuración y documentación). La aplicación, no el modelo, decide cuándo cargarlos en el contexto.

Prompts reutilizables

Plantillas de prompt reutilizables que aceptan argumentos, como comandos slash. El usuario las selecciona y activa para estandarizar flujos repetitivos.

Error común: "MCP son solo herramientas"

La mayoría de las introducciones se centran solo en las herramientas, pero los recursos y los prompts reutilizables son igual de importantes. Los recursos permiten que el servidor entregue datos contextuales sin que el modelo tenga que "invocar" nada. Los prompts reutilizables estandarizan interacciones repetitivas. Adiciones más recientes como Elicitation (el servidor solicita información al usuario humano) y Sampling (el servidor pide al cliente completions del LLM) amplían el protocolo. Pensar en MCP solo como "herramientas" deja fuera la mitad del protocolo.

Arquitectura MCP: hosts, clientes y servidores

MCP define tres roles en su arquitectura. Comprender la función de cada componente es indispensable para diseñar sistemas robustos:

Host

La aplicación con la que interactúa el usuario o sistema (tu backend, asistente o interfaz). El host crea y gestiona clientes MCP, aplica políticas de seguridad y coordina con el modelo.

Cliente

Un conector de protocolo que mantiene una sesión 1:1 con un servidor. Negocia capacidades ("¿qué puedes hacer?"), rutea mensajes y gestiona el ciclo de vida de la conexión.

Servidor

Un programa ligero que expone herramientas, recursos y prompts bajo el estándar MCP. Puede ser un proceso local o un servicio remoto en la nube (Postgres, CRM, APIs).

TransporteCómo funcionaIdeal paraEstado
stdioEl cliente ejecuta el servidor como subproceso local mediante stdin/stdout.Herramientas locales: sistema de archivos, ejecución de código, bases localesVigente
HTTP con streamingEndpoint HTTP único. El cliente envía solicitudes POST y el servidor transmite respuestas vía SSE con soporte de sesiones.Servidores remotos en la nube: SaaS, bases compartidas, serverlessVigente (marzo 2025)
HTTP + SSEEndpoints separados de SSE y POST.Transporte remoto heredadoObsoleto

Autenticación en servidores remotos

Los servidores remotos utilizan OAuth 2.1 con PKCE. El cliente gestiona el token Bearer en cada petición, permitiendo un acceso seguro a herramientas y bases de datos sin exponer jamás credenciales maestras al modelo de IA.

MCP y tool calling: dónde se ubica en el stack

Los LLMs poseen la capacidad nativa de emitir JSON estructurado para invocar funciones (tool calling). MCP no reemplaza esta capacidad: es la capa de estandarización y descubrimiento que se sitúa por encima.

  1. 1Tu aplicación: la aplicación host (asistente, backend Sentina, app empresarial).
  2. 2Capacidad del modelo (tool calling): el LLM emite JSON estructurado definiendo qué función llamar.
  3. 3Capa de protocolo (MCP): protocolo estandarizado de descubrimiento, conexión y ejecución.
  4. 4Servicios externos: bases de datos, APIs, archivos y herramientas SaaS.

La diferencia clave: sin MCP debes codificar a mano cada esquema de herramienta y lógica de ejecución para cada modelo. Con MCP apuntas tu aplicación al servidor MCP y las herramientas se descubren automáticamente mediante el protocolo estándar, funcionando indistintamente con Claude, GPT, Gemini o modelos locales.

El modelo mental clave

Tool calling es el motor; MCP es la red de autopistas. Sin tool calling el modelo no puede invocar funciones. Sin MCP cada integración es un camino de terracería que debes pavimentar desde cero. MCP entrega una autopista estándar por donde cualquier aplicación viaja hacia cualquier herramienta.

MCP en la práctica: cómo opera paso a paso

Veamos un flujo real de descubrimiento y ejecución cuando un usuario o sistema consulta datos a través de un servidor MCP:

  1. 1Conexión: al iniciar, el cliente se conecta al servidor y negocian capacidades.
  2. 2Descubrimiento: el cliente invoca tools/list y el servidor devuelve las herramientas disponibles con sus descripciones y esquemas.
  3. 3Inyección: el host inyecta las definiciones de herramientas descubiertas en el contexto del modelo.
  4. 4Invocación: el modelo decide invocar una herramienta. El cliente reenvía la solicitud al servidor mediante tools/call.
  5. 5Ejecución: el servidor ejecuta la función (lee la base, consulta la API, etc.) y devuelve el resultado.
  6. 6Bucle: el modelo recibe el resultado y evalúa si necesita ejecutar otra herramienta o responder al usuario (bucle agéntico).

No tienes que reescribir esquemas manualmente. El servidor MCP los provee dinámicamente y puede emitir notificaciones si sus herramientas cambian sin necesidad de reiniciar la aplicación.

El ecosistema MCP

El ecosistema MCP incluye un registro oficial con miles de servidores y SDKs oficiales en Python, TypeScript, C# y Java.

Datos y bases de datos

PostgreSQL, MySQL, Supabase, MongoDB. Consultas, inspección de esquemas y gestión de datos desde flujos de IA.

Herramientas para desarrolladores

GitHub, GitLab, Jira, Linear, Sentry. Gestión de repositorios, incidencias, despliegues y monitoreo.

Comunicación y colaboración

Slack, WhatsApp, Gmail, Google Calendar, Microsoft 365. Lectura de mensajes, agendamiento y envío de respuestas.

Archivos y almacenamiento

Sistemas locales, Google Drive, Dropbox, AWS S3. Búsqueda y gestión de documentos corporativos.

Búsqueda e información web

Búsqueda web en vivo, scraping y automatización de navegación con Puppeteer.

Infraestructura en la nube

Servidores MCP en contenedores Docker, Cloudflare, AWS, Google Cloud y Azure.

Construir vs. reutilizar

Antes de construir una integración propietaria, verifica el registro. Si ya existe un servidor MCP, ahorras semanas de desarrollo. Si lo construyes, beneficias a cualquier aplicación compatible con el estándar.

Adopción y respaldo de la industria

En pocos meses, Anthropic, OpenAI, Google y Microsoft adoptaron el mismo protocolo.

  1. 1Noviembre 2024: Anthropic lanza MCP como protocolo abierto y con soporte nativo en Claude Desktop.
  2. 2Finales de 2024: Cursor, Replit, Zed y Block se convierten en los primeros adoptantes e integran MCP en sus productos.
  3. 3Marzo 2025: OpenAI anuncia soporte de MCP para el Agents SDK, la Responses API y ChatGPT. Se publica la especificación 2025-03-26, que incorpora el transporte HTTP con streaming.
  4. 4Abril 2025: Google anuncia la integración de MCP en Google Cloud y el ecosistema Gemini.
  5. 52025: Microsoft integra MCP en Copilot Studio y VS Code.
  6. 6Septiembre 2025: se lanza el registro oficial de MCP con servidores de Stripe, Notion, GitHub y Postman.
  7. 7Noviembre 2025: se publica la especificación 2025-11-25 (versión vigente), que añade la primitiva experimental Tasks para flujos de trabajo agénticos, un OAuth simplificado, Sampling combinado con herramientas y el framework de extensiones.
  8. 8Enero 2026: está disponible la extensión MCP Apps para tableros interactivos e interfaces gráficas integradas.
  9. 9Marzo 2026: hoja de ruta empresarial con escalabilidad horizontal, sesiones sin estado, pistas de auditoría y gobernanza formal.
  • Gobernanza abierta: transparente, mediante grupos de trabajo y propuestas de mejora de especificación (SEPs).
  • Marco de extensiones: permite incorporar nuevas capacidades sin romper la compatibilidad con clientes existentes.
  • Prioridades 2026: evolución del transporte (escalabilidad horizontal, sesiones sin estado), comunicación entre agentes (primitiva Tasks, semántica de reintentos), preparación empresarial (pistas de auditoría, SSO, soporte de gateway) y triggers basados en eventos.

Por qué esto importa para arquitectos y empresas

La convergencia de los proveedores en un protocolo común significa que las herramientas y servidores que construyas hoy seguirán funcionando con otros modelos, protegiendo tu inversión tecnológica.

Cuándo usar MCP frente a herramientas personalizadas

MCP añade una capa de estandarización que aporta portabilidad. Evalúa cuándo conviene adoptarlo frente a conectores nativos:

Usar MCP cuando

Sistemas multi-herramienta: necesitas integrar múltiples servicios. La estandarización se amortiza a partir de 3 o 4 integraciones.
La portabilidad es prioritaria: quieres que tus herramientas funcionen con distintos proveedores de IA sin rehacer código.
Ya existe un servidor en el ecosistema: aprovechas servidores probados de la comunidad en lugar de programar desde cero.
Flexibilidad y modularidad: permite añadir o remover integraciones dinámicamente sin tocar el código fuente de la app.

Usar herramientas personalizadas cuando

Propósito simple y único: solo requieres una función básica y no se justifica levantar un servidor de protocolo.
Ruta crítica de ultra baja latencia: para llamadas de altísima frecuencia donde cada milisegundo cuenta, la llamada directa es más rápida.
Control estricto de dominio: lógica de negocio propietaria donde requieres control absoluto sobre reintentos y manejo de excepciones.
Protocolos propietarios cerrados: el servicio externo utiliza un protocolo legacy cerrado que no encaja de forma limpia en MCP.

El enfoque híbrido recomendado

En Sentina recomendamos el enfoque híbrido: MCP para integraciones estándar (Slack, WhatsApp, CRM, PostgreSQL) y conectores nativos dedicados para la lógica nuclear de tu negocio.

CapaQué haceEjemplos
OrquestaciónEncadena herramientas, gestiona flujos agénticos, memoria y razonamientoLangChain, CrewAI, Autogen
Protocolo (MCP)Estandariza cómo las aplicaciones de IA descubren e invocan herramientasModel Context Protocol
Capacidad del LLMCapacidad del modelo de emitir llamadas a funciones estructuradasTool calling / function calling
Contratos de APIDefine cómo se comunican los servicios a nivel de transporte HTTPREST, GraphQL, gRPC, OpenAPI

A2A: el protocolo complementario de agente a agente

Mientras MCP conecta agentes con herramientas (eje vertical), protocolos como A2A conectan agentes entre sí (eje horizontal), complementándose en arquitecturas multi-agente.

Seguridad y confianza: riesgos reales y mitigación

MCP otorga a los modelos acceso a sistemas reales: bases de datos, APIs y archivos. Este poder exige diseñar perímetros de seguridad y límites de confianza estrictos:

  • Envenenamiento de herramientas (tool poisoning): instrucciones maliciosas ocultas en las descripciones de herramientas que alteran el comportamiento del modelo o mutan tras su instalación para filtrar datos sensibles.
  • Falta de autenticación obligatoria: el protocolo no impone autenticación por defecto; es responsabilidad del equipo configurar OAuth 2.1 y restringir accesos locales.

Responsabilidad de seguridad en Sentina

En Sentina aplicamos el principio de mínimo privilegio: auditamos servidores, aislamos credenciales mediante secretos encriptados y validamos las salidas de herramientas para blindar tu operación.

Conceptos erróneos sobre MCP

  • "MCP es una API": MCP es un protocolo de mediación e intercambio de contexto entre modelos y herramientas, no una API REST ni un gateway tradicional.
  • "MCP reemplaza a tool calling": MCP se apoya en tool calling; el modelo decide qué función invocar y MCP gestiona la conexión estándar con la herramienta.
  • "MCP reemplaza a RAG": MCP es para ejecución de herramientas y acceso contextual; RAG es para recuperación documental en grandes bases de conocimiento. Ambos pueden usarse juntos sin conflicto.
  • "Cualquier modelo se comporta igual con MCP": MCP estandariza la interfaz de conexión, pero la calidad del razonamiento depende de la capacidad del modelo de IA elegido.
  • "Los servidores MCP son centralizados": los servidores MCP suelen ejecutarse como procesos dedicados o servicios aislados para cada entorno.
  • "Las herramientas son agentes": una herramienta ejecuta una única función y devuelve un resultado. Un agente planea, razona, itera y se autocorrige. La herramienta es el martillo; el agente es el carpintero que decide cuándo y cómo usarlo. MCP entrega herramientas, no agentes.

Conclusiones clave para empresas

  • MCP es el conector universal: resuelve el problema de integración M x N. Construyes una vez y conectas con cualquier proveedor de IA.
  • Tres primitivas indispensables: herramientas (acciones controladas por el modelo), recursos (datos controlados por la aplicación) y prompts reutilizables (plantillas controladas por el usuario).
  • Se apoya sobre tool calling: tool calling es la capacidad del modelo; MCP es la tubería estándar que la hace modular y portable.
  • La seguridad requiere atención activa: audita servidores, limita permisos y aplica validación estricta a los datos devueltos por herramientas.
  • Un ecosistema consolidado: miles de servidores activos y respaldo unánime de Anthropic, OpenAI, Google y Microsoft.
  • El enfoque híbrido es el más pragmático: utiliza MCP para integraciones estándar y conectores nativos para procesos propietarios críticos.
MCPTool callingIntegraciones

¿Quieres este tipo de resultado para tu operación?

Mapeemos en conjunto dónde tus sistemas están perdiendo tiempo y dinero, y qué se necesita para resolverlo.

Agendar diagnóstico

Seguir leyendo