MCP en IA significa Model Context Protocol. Descubre cómo los hosts, clientes y servidores conectan la IA con herramientas y datos, además de MCP frente a API y los principales riesgos de seguridad.
MCP en IA significa Model Context Protocol. Es un estándar abierto que ayuda a las aplicaciones de IA a conectarse con herramientas externas, fuentes de datos y flujos de trabajo mediante una interfaz común. MCP no sustituye a las API, las llamadas a funciones ni RAG. En su lugar, ofrece a las aplicaciones de IA una forma más coherente de descubrir y utilizar esas capacidades.
MCP significa Model Context Protocol.
Es un estándar de código abierto para conectar aplicaciones de IA con sistemas externos, como archivos, bases de datos, herramientas de búsqueda, calendarios, repositorios de código y software empresarial. La documentación oficial de MCP lo compara con un puerto USB-C: distintos dispositivos pueden utilizar el mismo estándar de conexión en lugar de requerir un cable nuevo para cada combinación.
Esta comparación es útil, pero también puede hacer que MCP parezca más sencillo de lo que es.
MCP no es un modelo de IA, una aplicación ni un sustituto de una API. Es un estándar de comunicación utilizado por aplicaciones y servidores de IA compatibles. La aplicación sigue necesitando un modelo de lenguaje que entienda la solicitud del usuario, mientras que los servicios conectados suelen seguir dependiendo de sus API existentes internamente.
Una definición más precisa sería:
MCP estandariza la forma en que una aplicación de IA descubre, se conecta e intercambia información con herramientas y fuentes de datos externas.
La palabra context es importante. Un modelo de lenguaje solo conoce lo que está incluido en sus datos de entrenamiento o lo que se proporciona durante la interacción actual. MCP puede dar a una aplicación de IA acceso a contexto adicional—como un registro actual de una base de datos, un archivo local o el resultado de una solicitud de API en tiempo real—cuando se necesita esa información.
Antes de MCP, los desarrolladores normalmente creaban integraciones independientes para cada combinación de aplicación de IA y servicio externo.
Imaginemos un asistente de IA que necesita trabajar con Google Calendar, GitHub, una base de datos de clientes y un sistema interno de facturación. Cada integración puede tener su propio formato de API, proceso de autenticación, definiciones de funciones y reglas de gestión de errores.
Ahora imaginemos crear de nuevo las mismas conexiones para otro asistente de IA.
MCP intenta reducir este trabajo repetido de integración. Un servicio puede exponer sus capacidades mediante un servidor MCP, mientras que las aplicaciones de IA compatibles pueden conectarse a través de un protocolo compartido.
Esto no significa que los desarrolladores puedan dejar de crear integraciones. Alguien todavía debe implementar el servidor MCP, conectarlo con el servicio subyacente, gestionar las credenciales, validar las solicitudes y mantener el sistema. El beneficio es la reutilización: una vez que una capacidad sigue el protocolo, puede ser más fácil conectarla con varios hosts de IA compatibles.
MCP es más valioso cuando empieza a aumentar el número de herramientas, fuentes de datos y clientes de IA. Para una aplicación conectada a un único servicio estable, una integración directa mediante API puede seguir siendo la opción más sencilla.
MCP utiliza una arquitectura cliente-servidor, pero la terminología puede resultar confusa porque intervienen tres partes.
El host es la aplicación de IA con la que interactúa el usuario. Puede ser un asistente de chat, un entorno de programación, una aplicación de escritorio o un agente de IA personalizado.
El host coordina la conversación, se comunica con el modelo de lenguaje, gestiona los permisos y decide qué conexiones MCP están disponibles.
Un cliente MCP es un componente dentro del host que mantiene una conexión con un servidor MCP.
Según la arquitectura oficial de MCP, un host normalmente crea una conexión de cliente independiente para cada servidor. Si una aplicación se conecta a un servidor de archivos y a un servidor de calendario, gestiona dos clientes MCP.
Un servidor MCP es un programa que pone capacidades específicas a disposición de los clientes MCP. Puede ejecutarse localmente en el dispositivo del usuario o de forma remota en otro servidor.
Un servidor MCP puede exponer tres tipos principales de capacidades:
El host y el servidor negocian primero qué funciones del protocolo admiten ambos. A continuación, el cliente puede solicitar una lista de las capacidades disponibles. Cuando el modelo decide que una herramienta es relevante, el host dirige la solicitud estructurada a través del cliente MCP hasta el servidor correcto.
El resultado vuelve a la aplicación de IA y se convierte en contexto adicional para la siguiente respuesta del modelo.
Supongamos que un desarrollador pide a un asistente de IA interno:
“Comprueba nuestro gasto en API de este mes. Si supera el presupuesto en más de un 20 %, crea una alerta para el equipo de ingeniería.”
Un flujo de trabajo MCP simplificado podría ser el siguiente:
get_api_usage y get_budget_limit.create_alert.MCP estandariza la parte intermedia de este proceso: descubrir las herramientas, describir sus requisitos de entrada, llamarlas y devolver resultados estructurados.
No realiza el cálculo por sí mismo, no proporciona el modelo de lenguaje ni sustituye a las API de facturación y mensajería.
Estos términos suelen presentarse como tecnologías competidoras. En la práctica, operan en capas diferentes y aparecen con frecuencia en la misma aplicación.
| Concepto | Qué resuelve | Cómo se relaciona con MCP |
|---|---|---|
| API | Permite que un sistema de software solicite datos o acciones a otro | Un servidor MCP suele llamar a las API existentes internamente |
| Llamada a funciones | Permite que un modelo genere una solicitud estructurada para una herramienta predefinida | Un host puede convertir las definiciones de herramientas MCP en funciones que el modelo pueda seleccionar |
| RAG | Recupera información externa relevante antes de que el modelo responda | Un servidor MCP puede exponer herramientas o recursos de recuperación, pero MCP no es RAG |
| MCP | Estandariza cómo las aplicaciones de IA compatibles se conectan e interactúan con herramientas y datos | Actúa como capa de conexión e interoperabilidad |
No. MCP y las API resuelven problemas relacionados, pero diferentes.
Una API define cómo se puede llamar a un servicio concreto. Por ejemplo, una API de facturación podría definir un endpoint que devuelva el uso de una cuenta.
MCP define cómo una aplicación de IA puede descubrir y utilizar una capacidad expuesta por un servidor compatible. Ese servidor puede llamar a la API de facturación para obtener los datos reales.
En otras palabras:
Una API conecta el software con un servicio. MCP ayuda a una aplicación de IA a trabajar con muchos servicios mediante un protocolo común.
Una integración directa mediante API puede seguir siendo más rápida y sencilla cuando una aplicación solo necesita una función fija. MCP resulta más atractivo cuando los desarrolladores quieren reutilizar herramientas en varios clientes de IA o permitir que las capacidades disponibles cambien dinámicamente.
No. Las llamadas a funciones son generalmente una capacidad del modelo. Los desarrolladores describen una o más funciones y el modelo produce argumentos estructurados cuando decide que debe utilizarse una función.
MCP opera alrededor de ese proceso. Puede ayudar a la aplicación a descubrir definiciones de herramientas desde servidores conectados, en lugar de exigir que cada herramienta esté codificada directamente en la aplicación.
El modelo aún puede depender de llamadas a funciones o herramientas para seleccionar una herramienta proporcionada por MCP.
No. La generación aumentada por recuperación, o RAG, es un método para recuperar información relevante y añadirla al contexto de un modelo antes de que responda.
Un servidor MCP podría exponer una herramienta de búsqueda de documentos que forme parte de un sistema RAG. Sin embargo, MCP no decide cómo se indexan los documentos, cómo se clasifican los resultados ni cómo se añade el texto recuperado a un prompt.
MCP puede transportar la solicitud y el resultado. El sistema de recuperación realiza la búsqueda.
MCP puede hacer que las herramientas sean más reutilizables entre aplicaciones compatibles. También puede permitir que una aplicación descubra las herramientas disponibles y sus entradas requeridas, en lugar de depender por completo de conexiones codificadas directamente.
Pero algunas afirmaciones habituales van demasiado lejos.
MCP no:
Tampoco proporciona a un modelo acceso sin restricciones a todos los servicios conectados. El host controla qué servidores están conectados, mientras que las capacidades del servidor y los permisos del usuario determinan qué se puede leer o modificar.
Vale la pena considerar MCP cuando una aplicación debe conectarse a varias herramientas o fuentes de datos, especialmente si esas capacidades pueden reutilizarse en distintos hosts de IA.
Entre las situaciones habituales se incluyen:
Una integración directa mediante API puede ser la mejor opción cuando la aplicación tiene un único flujo de trabajo específico, utiliza un solo servicio o necesita un control preciso y de bajo nivel sobre cada solicitud. Añadir un servidor MCP introduce otro componente que hay que implementar, proteger, probar y supervisar.
MCP reduce parte de la repetición de las integraciones. No elimina las decisiones arquitectónicas comprometidas.
MCP no es seguro ni inseguro automáticamente. La seguridad depende del host, el servidor, sus servicios subyacentes, el flujo de autenticación y los permisos concedidos para cada acción.
Un servidor conectado puede recibir información confidencial de la aplicación de IA. Una herramienta con acceso de escritura también podría modificar archivos, enviar mensajes, crear registros o activar otras acciones externas.
La guía oficial de seguridad de MCP abarca riesgos como el reenvío de tokens, la falsificación de solicitudes del lado del servidor, el secuestro de sesiones, los servidores locales comprometidos y los ataques de delegado confundido. Son riesgos de implementación, no ventajas teóricas que desaparezcan porque un sistema utilice un protocolo estándar.
Los desarrolladores deberían aplicar varios controles básicos:
OpenAI también advierte que los servidores MCP personalizados pueden recibir datos y realizar acciones externas, y recomienda conectarse únicamente a servidores de confianza. Su implementación actual requiere confirmación antes de realizar acciones de escritura en las conversaciones de ChatGPT, pero los desarrolladores no deberían asumir que todos los clientes MCP aplican la misma política. Documentación de MCP de OpenAI
A fecha de julio de 2026, la última especificación estable de MCP sigue siendo la versión publicada el 25 de noviembre de 2025. El proyecto oficial ha declarado que no ha publicado otra versión de la especificación desde entonces. La hoja de ruta de MCP para 2026 describe trabajos previstos, no funciones ya garantizadas en el protocolo estable.
La especificación actual define dos transportes estándar:
stdio para la comunicación con procesos locales.HTTP transmitible sustituyó al transporte HTTP+SSE anterior, aunque los clientes y servidores pueden conservar la compatibilidad con versiones anteriores. La especificación de transporte actual también incluye requisitos y recomendaciones sobre autenticación, validación del origen, vinculación a redes locales y gestión de sesiones.
La gobernanza de MCP también ha cambiado. En diciembre de 2025, el protocolo se convirtió en un proyecto fundador de la Agentic AI Foundation de Linux Foundation. La fundación informó de más de 10.000 servidores MCP publicados y de su adopción en productos como ChatGPT, Claude, Gemini, Microsoft Copilot, Cursor y Visual Studio Code. Anuncio de Linux Foundation
La hoja de ruta de 2026 se concentra en cuatro áreas: escalabilidad del transporte, comunicación entre agentes, gobernanza y preparación empresarial. Los registros de auditoría, la autenticación integrada con SSO, la portabilidad de la configuración y el comportamiento de las pasarelas se encuentran entre los problemas empresariales que aún se están resolviendo.
Este último punto es importante. MCP ha dejado de ser un experimento para herramientas de desarrollo locales, pero algunos aspectos de su modelo de seguridad y operaciones empresariales todavía están madurando.
GPT Proto y MCP pertenecen a capas diferentes de una aplicación de IA.
MCP conecta la aplicación con herramientas y contexto externos. La aplicación sigue necesitando un modelo que entienda la solicitud, elija una acción y genere la respuesta final.
Se puede acceder a ese modelo mediante un proveedor de API de modelos. Los desarrolladores que utilizan el catálogo de modelos de GPT Proto pueden elegir entre modelos de texto y de razonamiento para esta capa de inferencia, mientras que los servidores MCP gestionan las conexiones con sistemas externos.
Una configuración simplificada podría contener:
Las dos capas son complementarias. Una API de modelos común puede facilitar las pruebas o el cambio del modelo que hay detrás de una aplicación; MCP puede reducir el trabajo repetido al conectar esa aplicación con varias herramientas.
TL;DR Mejores API directas: OpenAI es la opción predeterminada más segura para uso general; Anthropic Claude destaca en programación y agentes de larga duración; Gemini es ideal para prototipos multimodales de bajo coste; y DeepSeek lidera en precio por token de texto. Mejores opciones multimodelo: OpenRouter es la opción más clara para probar muchos LLM. GPTProto es más adecuado cuando un producto necesita modelos de texto, imagen y vídeo bajo una sola clave de API y un saldo compartido. Mejores opciones de infraestructura: Amazon Bedrock encaja en implementaciones empresariales gobernadas por AWS, mientras que Replicate, fal.ai y Together AI son más adecuados para inferencia de modelos abiertos o medios generativos. No existe un ganador universal. Compara la adecuación a la carga de trabajo, la cobertura de modelos, las unidades reales de facturación, los controles de producción y el coste de migración. Los precios y la disponibilidad se comprobaron el 14 de julio de 2026; verifica las páginas actuales de los proveedores antes de implementar.
Tiffany Layne | 2026-07-15
En resumen: Kimi K3 es el modelo de programación más potente cuando la tarea es difícil, prolongada o visual. Supera a GLM-5.2 en la comparación de programación publicada por Moonshot y acepta imágenes y vídeo mediante su servicio alojado. GLM-5.2 sigue siendo la mejor opción predeterminada para el trabajo rutinario en repositorios: cuesta mucho menos, es más pequeño de operar y utiliza la permisiva licencia MIT. Kimi K3 también ha publicado sus pesos, pero su repositorio de 1,56 TB, la implementación recomendada con más de 64 aceleradores y su licencia personalizada hacen que el autoalojamiento suponga un compromiso considerablemente mayor. Elige Kimi cuando la capacidad sea el factor limitante; elige GLM cuando el coste y la sencillez operativa sean importantes cada día. La parte interesante de la comparación de código GLM-5.2 frente a Kimi K3 no es que ambos modelos puedan escribir un componente de React o resolver un algoritmo corto. Los modelos de este nivel ya superan ese umbral. La pregunta útil es qué ocurre cuando la tarea se complica: una auditoría de un repositorio, una migración de varios archivos, un error que solo aparece en una captura de pantalla o un prototipo jugable de Three.js que debe mantener la coherencia entre varios sistemas. Ahí es también donde la diferencia de precio empieza a importar. Kimi K3 ofrece mejores resultados en las pruebas públicas más difíciles, pero su precio oficial de salida es más de tres veces superior al de GLM-5.2. Un equipo que ejecute miles de revisiones ordinarias puede realizar más trabajo por dólar con GLM. Un desarrollador que intente rescatar un proyecto visual difícil probablemente pagará con gusto por K3.
Tiffany Layne | 2026-07-28
He visto a muchas personas generar una ilustración de IA preciosa, entusiasmarse y luego abandonar discretamente alrededor de la página cuatro. La primera imagen nunca es el problema. El problema es que la página cuatro siga mostrando al mismo zorro de la página uno — y que cada página sea lo bastante nítida como para imprimirse de verdad. La mayoría de los sitios que se anuncian como «creadores de libros infantiles con IA» ocultan ambos problemas detrás de un botón amigable y luego te entregan una imagen de 1024 píxeles que se vuelve borrosa en cuanto la impresora la toca. Esta guía toma otro camino: una pequeña canalización de API repetible que ejecutas tú mismo. Está dirigida a quienes quieren control programático — generación por lotes, el mismo personaje en 24–32 páginas y archivos que cumplen las especificaciones de impresión —, no un juguete de un solo clic. Si solo quieres una imagen para la hora de dormir en tu teléfono, una herramienta sin código es realmente más rápida y deberías usarla. Si quieres producir un libro completo y mantener los costes y la calidad bajo control, sigue leyendo. Al final tendrás un flujo de trabajo que genera un conjunto de páginas interiores listas para imprimir (300 DPI) y coherentes en cuanto al personaje, además de una portada, utilizando dos modelos mediante una sola clave de API de GPTProto , por aproximadamente un dólar de coste de generación.
Katherine Lawrence | 2026-06-12
Conectar GLM-5.2 a un agente de programación toma unos minutos. La parte más difícil es darle suficiente contexto para corregir un repositorio sin dejar que se desvíe. Esta distinción es importante. Un modelo puede escribir una función limpia en una ventana de chat y aun así fallar en una tarea de ingeniería real porque edita la capa equivocada, rompe un contrato de API, omite la suite de pruebas o pasa la mitad de su contexto leyendo archivos generados. GLM-5.2 está diseñado para trabajos de programación más largos y basados en herramientas, pero el modelo sigue necesitando un flujo de trabajo disciplinado a su alrededor. Esta guía presenta tres opciones prácticas: usar GLM-5.2 con Claude Code, llamar a la API de GLM-5.2 en GPTProto desde un agente compatible con OpenAI y ejecutar los pesos abiertos localmente. Después muestra cómo delimitar una tarea a nivel de repositorio, gestionar el contexto de 1 M de tokens, verificar los cambios y estimar el coste real de los tokens. En resumen Usa Claude Code con el endpoint compatible con Anthropic de Z.ai si ya trabajas con ese agente de terminal. Usa el endpoint compatible con OpenAI de GPTProto para Cline, OpenCode, un agente personalizado o una aplicación que ya use el SDK de OpenAI. No envíes un monorepo completo por defecto solo porque GLM-5.2 acepte hasta 1 M de tokens. Empieza con un mapa del repositorio, los archivos relevantes, las restricciones y los comandos de prueba. Usa un razonamiento Alto para la investigación rutinaria y Máximo para trabajos ambiguos que involucren varios archivos, donde un plan incorrecto sería costoso. Considera que los cambios del agente no son fiables hasta que superen la compilación, el lint, las comprobaciones de tipos y las pruebas del repositorio. Ejecuta el modelo localmente solo cuando la privacidad, el control o el uso continuo justifiquen una infraestructura importante. «Pesos abiertos» no significa «del tamaño de un portátil».
Schuyler Stacy | 2026-07-17
