¿Qué es MCP en IA? Protocolo de Contexto de Modelo Explicado

Por qué la IA necesita conexiones externas

Un asistente de IA puede explicar código o redactar una agenda de reunión bien. Pídele que inspeccione un problema de repositorio en vivo o los archivos privados detrás de ese problema, y aparece una brecha. Lo mismo sucede con tu calendario o una base de conocimiento interna. El modelo puede ser capaz de interpretar la información, pero la aplicación aún necesita una forma controlada de recuperarla.

Los desarrolladores tradicionalmente construyen esas conexiones una a la vez. Un asistente obtiene una integración de repositorio. Otro necesita un conector de calendario, mientras que un tercero accede al mismo rastreador de problemas a través de una interfaz diferente. A medida que se multiplican las aplicaciones de IA y los sistemas externos, también lo hacen sus integraciones. Cada conexión trae decisiones de autenticación y permisos, seguidas de responsabilidades de mantenimiento y manejo de datos en curso. A escala, las conexiones puntuales se convierten en trabajo de ingeniería repetido.

La pieza que falta no es un modelo más inteligente. Es un límite de conexión reutilizable entre aplicaciones de IA y contexto externo o acciones. Esta guía localiza ese límite y rastrea una solicitud a través de él. Luego separa conceptos cercanos y te ayuda a juzgar su idoneidad.

Qué es MCP y por qué existe

Model Context Protocol (MCP) es un estándar abierto que proporciona a las aplicaciones de IA compatibles una forma consistente de conectarse a sistemas externos que proporcionan datos, herramientas y flujos de trabajo reutilizables. Esto reafirma la introducción oficial. “Estándar abierto” significa que los proveedores pueden implementar reglas públicas compartidas en lugar del formato de conector privado de un producto. En la práctica, una capacidad publicada a través de MCP puede servir a varios hosts compatibles, sujeto a lo que cada host admite y permite.

La analogía común es “USB-C para aplicaciones de IA”. En lugar de inventar un conector diferente para cada emparejamiento, los productos pueden implementar un estándar de conexión compartido. El límite importa tanto como la analogía. La compatibilidad no prueba que un sistema sea seguro, autorizado o de alta calidad. Tampoco significa que cada host admita las mismas características.

Anthropic presentó MCP el 25 de noviembre de 2024, luego lo contribuyó a la Agentic AI Foundation de la Linux Foundation en diciembre de 2025. Ahora es un proyecto de código abierto y entre proveedores en lugar de una característica propietaria solo de Anthropic. El soporte es generalizado en las principales aplicaciones de IA y herramientas de desarrollador, aunque el comportamiento de implementación y aprobación varía.

Arquitectura MCP: Hosts, Clientes y Servidores

El host MCP es la aplicación de IA orientada al usuario. Coordina la interfaz, el modelo y las conexiones a sistemas externos. La política del host determina qué capacidades aparecen y cuándo se requiere aprobación. El host también devuelve resultados al usuario. El modelo opera dentro de él; normalmente no se conecta directamente a sistemas externos.

Un cliente MCP es el componente que habla el protocolo que el host crea o gestiona para una conexión de servidor. Hay un cliente por cada servidor conectado. La interfaz del producto puede ocultarlo, pero el cliente y el host siguen siendo distintos. Los clientes separados mantienen las conexiones y las capacidades expuestas bajo el control del host.

Un servidor MCP es un programa que expone capacidades a través de MCP, no una clase de hardware. El mismo servidor podría ejecutarse en una laptop y trabajar con archivos locales seleccionados bajo la cuenta del usuario. Ejecútalo como un servicio remoto y la identidad de red y la disponibilidad se convierten en preocupaciones operativas. Su rol MCP sigue siendo el mismo en ambas ubicaciones.

Los servidores exponen tres tipos principales de capacidades. Una herramienta es una operación, como recuperar un problema o crear un evento de calendario. Un recurso es contexto legible, como un archivo, registro o esquema. Un prompt es una plantilla de interacción reutilizable, como un prompt de revisión de incidentes.

User request
     ↓
┌─ MCP host: AI application ───────────────────────────┐
│ Interface + model + policy/approval + result handling│
│                                                     │
│ ├─ MCP client A ────────────────────────────────────┼─⇄ Local MCP server
│ └─ MCP client B ────────────────────────────────────┼─⇄ Remote MCP server
└─────────────────────────────────────────────────────┘          │
                                                                 ├─ each exposes tools / resources / prompts
                                                                 ├─ local server ⇄ local files or application
                                                                 └─ remote server ⇄ external API, database, or service

Request/action travels →        Result/context returns ←

La descripción general oficial de la arquitectura profundiza más. Un servidor puede estar frente a una API o base de datos existente. También puede exponer acceso a una interfaz de línea de comandos, sistema de archivos o servicio empresarial. MCP estandariza la exposición e intercambio; el sistema subyacente almacena datos o realiza la acción.

En términos de servicio técnico, el host coordina la visita. Cada cliente es un empleado que habla el protocolo asignado a un mostrador, mientras que cada servidor publica un menú de capacidades. Ese menú muestra disponibilidad, no seguridad.

Cómo funciona una solicitud MCP

Considera esa arquitectura en movimiento. Un desarrollador le pide a un asistente de codificación que inspeccione un problema y archivos de repositorio relevantes, luego explique la causa probable. La tarea es de solo lectura: investigar, pero no editar, confirmar, fusionar o desplegar.

Un flujo conceptual típico tiene seis etapas:

1. El host se conecta. El asistente está configurado para alcanzar los servidores de problemas y repositorio a través de sus clientes MCP.
2. El host descubre y filtra capacidades. Los clientes aprenden qué ofrecen sus servidores; el host reduce el conjunto por configuración, relevancia y permiso.
3. El usuario hace la pregunta. El host le da al modelo la solicitud, el contexto disponible y solo las descripciones de capacidad relevantes.
4. El modelo propone una operación. Selecciona una herramienta de lectura apropiada. El host aplica política y solicita aprobación si es necesario; el comportamiento varía según el host y la configuración.
5. El servidor realiza el trabajo. Llama al rastreador de problemas, interfaz de repositorio o API y devuelve resultados estructurados a través del cliente.
6. El modelo interpreta la evidencia. El host agrega la información devuelta al contexto del modelo, y el modelo la explica al usuario.

Aquí, descubrimiento de capacidades significa que el cliente aprende qué ofrece actualmente un servidor en lugar de depender de un menú codificado en la aplicación. El proveedor puede evolucionar ese menú sin redefinirlo por separado dentro de cada host.

Como muestra el diagrama, la solicitud se mueve del host al cliente, servidor y sistema subyacente. Los resultados regresan por el mismo camino antes de que el modelo los use.

Un conjunto de capacidades pequeño y específico de tarea es a menudo mejor que el catálogo completo. La exposición limitada restringe privilegios innecesarios. Menos descripciones también reducen el uso de tokens, costo y latencia mientras hacen que la selección de herramientas sea menos confusa. El descubrimiento proporciona opciones; el host decide cuáles entran en la interacción.

MCP, APIs, Llamadas de función, Agentes y RAG

MCP, APIs, llamadas de función, agentes y generación aumentada por recuperación (RAG) a menudo se presentan como rivales. Resuelven problemas diferentes y regularmente trabajan juntos.

La cadena en capas puede verse así: servicio/API subyacente → servidor MCP → cliente/host MCP → selección de herramientas del modelo → bucle de agente opcional.

En el ejemplo del repositorio, una API suministra los datos y un servidor MCP expone una operación de lectura limitada. La llamada de función permite que el modelo proponga esa operación. Un bucle de agente opcional puede repetir lecturas aprobadas. El servicio mantiene su interfaz existente mientras que los hosts compatibles ganan una forma estándar de descubrir la operación.

“Conector” y “complemento” son etiquetas de producto, no sinónimos de MCP. Cualquiera puede usar MCP o una integración propietaria; el nombre solo no revela el protocolo.

Casos de uso prácticos de MCP

Los casos de uso de MCP tienen dos formas prácticas. Las operaciones de contexto y lectura recopilan evidencia sin cambiar la fuente. Las acciones consecuentes crean un efecto externo, como actualizar datos o enviar un mensaje. MCP puede exponer ambas; la sección de seguridad explica los controles más estrictos necesarios para el segundo grupo.

Los proyectos iniciales más seguros son, por lo tanto, estrechos y con mucha lectura:

Los equipos de desarrollo pueden usar un editor, interfaz de chat y herramienta de revisión contra los mismos repositorios y problemas. Una capacidad compartida proporciona a cada host la misma evidencia limitada, reduciendo el trabajo de configuración antes de que pueda comenzar una investigación.

Para equipos de negocios, el valor inmediato es una preparación más rápida. El contexto de base de conocimiento o CRM aprobado puede respaldar un borrador de respuesta o resumen de reunión, para que el personal dedique menos tiempo a recopilar antecedentes antes de la revisión.

Los auto-hospedadores pueden usar el mismo patrón para verificar archivos privados y servicios de laboratorio doméstico sin moverse entre varias interfaces. Los equipos en la nube y de TI pueden llevar registros, métricas y runbooks a una investigación, facilitando la correlación de evidencia de incidentes.

En las cuatro filas, un proyecto inicial útil tiene una fuente nombrada, una tarea clara y un resultado observable. Eso hace que su valor sea más fácil de juzgar antes de que el alcance crezca.

MCP Local vs Remoto

Un servidor MCP es un rol de software que puede ubicarse en dos lugares comunes. Un servidor local es un proceso que el host inicia o alcanza a través de stdio, lo que significa entrada/salida estándar directa entre procesos locales. Se encuentra cerca de archivos y aplicaciones locales, a menudo sirve a un cliente y puede ejecutarse con los privilegios del usuario.

Un servidor remoto es un servicio continuamente accesible a través de HTTPS utilizando el transporte remoto de MCP (actualmente HTTP Transmisible). Puede servir a uno o muchos hosts compatibles. “Remoto” significa accesible por sus clientes de red previstos, no necesariamente expuesto a la internet pública.

Local:  AI host → stdio → local MCP process → scoped local files/app
                        [same-machine trust boundary]

Remote: AI host → HTTPS → remote MCP service → API/database/business system
                        [network + identity trust boundary]

Ejecutar MCP de forma remota crea responsabilidades de servicio ordinarias. El acceso y los secretos necesitan protección, mientras que los registros y la supervisión hacen visible el comportamiento. La aplicación de parches, la disponibilidad y los límites de red también se convierten en preocupaciones operativas. La siguiente sección cubre estos controles en detalle.

Un VPS de AlexHost estándar puede servir para un pequeño servicio o puerta de enlace MCP remota siempre activa. El alojamiento de IA de AlexHost es importante solo cuando la inferencia de modelo autohospedada es una carga de trabajo separada y computacionalmente intensiva. MCP en sí no requiere GPU.

Seguridad y confianza de MCP

La compatibilidad se convierte en una cuestión de seguridad cuando los datos y las acciones cruzan el límite. Un servidor puede recibir datos seleccionados o exponer herramientas que desencadenen acciones externas. El nombre y la descripción de una herramienta son afirmaciones de software, no prueba de comportamiento seguro. La misma precaución se aplica a sus anotaciones.

La ubicación cambia el riesgo. Un servidor local es código ejecutable que puede heredar el acceso a archivos y red del usuario. Un servidor remoto recibe datos a través de una red, por lo que su identidad y controles de autorización importan. La conexión también depende de la protección del transporte y la confianza en el operador.

⚠️ Advertencia: La compatibilidad de conexión no es un certificado de confianza. Como con USB-C, la interoperabilidad no decide si un componente debe recibir sus datos o permisos.

Utilice esta línea de base de seis partes:

1. Elija deliberadamente. Prefiera servidores oficiales, revisados o controlados internamente. Inspeccione el comando exacto y el paquete antes de ejecutar código local.
2. Mantenga la exposición estrecha. Permita solo servidores, capacidades, directorios, registros y herramientas necesarios. Comience de solo lectura y aplique el principio de menor privilegio: el acceso mínimo requerido.
3. Controle acciones consecuentes. Requiera aprobación explícita o una política estricta para enviar, eliminar, pagar, implementar, cambiar permisos y operaciones similares.
4. Proteja el acceso remoto. Utilice autenticación y autorización apropiadas, HTTPS, credenciales limitadas y manejo cuidadoso de secretos.
5. Aisle procesos locales. Arenícelos donde sea práctico, especialmente cuando no necesitan acceso amplio al sistema de archivos o red.
6. Conserve registros útiles. Registre conexiones, intercambio de datos, llamadas de herramientas, aprobaciones, fallos y resultados para auditoría.

Un registro ayuda al descubrimiento, una licencia de código abierto permite la inspección, y una implementación válida establece compatibilidad. Ninguno por sí solo garantiza seguridad. La guía oficial de seguridad de MCP profundiza más para implementadores.

La seguridad sigue siendo compartida. El host controla la exposición, y el servidor aplica sus límites. El operador protege la implementación y las credenciales, mientras que el sistema subyacente autoriza cada solicitud.

Cuándo usar MCP

MCP justifica su límite adicional cuando las capacidades suministradas independientemente necesitan reutilización en hosts compatibles. El descubrimiento en tiempo de ejecución también puede importar cuando esas capacidades cambian con el tiempo. Un límite compartido puede entonces mantener la gobernanza consistente mientras permite que la capacidad y el host evolucionen por separado.

Si una aplicación necesita una integración pequeña y estable, una llamada API directa o una función propiedad de la aplicación puede ser más simple. Si el código ya conoce el orden de operación, use un flujo de trabajo determinista: una secuencia predefinida que favorece la previsibilidad y la auditoría sobre los pasos seleccionados por el modelo.

Use estas seis preguntas como filtro práctico:

1. ¿Más de un host AI compatible reutilizará la capacidad? Si no, una integración directa puede ser suficiente.
2. ¿Debe la capacidad evolucionar independientemente del host o ser descubierta dinámicamente? Si no, las funciones propiedad de la aplicación pueden ser más simples.
3. ¿Debe un modelo elegir entre operaciones, o la secuencia ya es conocida? Las secuencias conocidas favorecen código determinista.
4. ¿Puede el equipo gobernar este límite? Si no, no agregue herramientas MCP consecuentes aún; aplique primero los controles de la sección de seguridad.
5. ¿La latencia agregada, los errores de selección de capacidad y las operaciones de servicio se justifican por la reutilización? Si no, mantenga el límite más pequeño.
6. ¿Los hosts objetivo admiten las primitivas y el comportamiento de aprobación que el proyecto necesita? Si no está seguro, verifique la compatibilidad antes de estandarizar en MCP.

Un “sí” al descubrimiento dinámico no es una razón para exponer el catálogo completo. Demasiadas descripciones consumen tokens, agregan costo y latencia, y hacen que la selección sea menos confiable. Más herramientas no garantizan una aplicación mejor.

Comience con la integración más simple que funcione. Elija MCP solo cuando la lista de verificación señale una ventaja clara sobre una integración directa.

Conclusión

Vuelve al asistente desde el principio. MCP no cambió la capacidad de razonamiento del modelo. Le dio al host una forma definida de recuperar contexto externo seleccionado.

El modelo mental es simple: el servidor expone; el cliente se conecta; el host controla; el sistema subyacente realiza el trabajo. MCP es una capa de conexión dentro de una pila de IA más grande.

Antes de adoptar MCP, identifica una capacidad estrecha y de solo lectura de la que se beneficiaría más de un host de IA. Si no puedes nombrar una, comienza con una integración directa en su lugar.