🧠 Fundamentos: Qué es MCP y por qué existe

Las integraciones de IA son puentes que permiten que los modelos de lenguaje se conecten a sistemas externos: bases de datos, API, herramientas de productividad y cualquier otro software. Sin integraciones, un modelo está limitado a lo que ya sabe.

Comprender el concepto de integraciones es el primer paso para entender por qué existe MCP. Necesitas conocer el problema antes de apreciar la solución.

Modelo de lenguaje, sistemas externos, APIs, herramientas, datos en tiempo real, acciones automatizadas.

Antes de MCP, cada integración entre un modelo de IA y una herramienta externa se construía de forma individual. Cada desarrollador creaba su propio puente, con su propio formato, autenticación y lógica de comunicación.

Entender el escenario anterior a MCP revela el problema que motivó su creación. Verás cómo el trabajo repetitivo y fragmentado consumía enormes recursos.

Integración ad hoc, código repetitivo, falta de estandarización, trabajo duplicado, fuerte acoplamiento.

El problema N×M ocurre cuando cada uno de los N modelos de IA necesita una integración específica para cada una de las M herramientas disponibles. El número total de integraciones necesarias crece de forma multiplicativa, lo que vuelve insostenible el ecosistema.

Este es el problema central que resuelve MCP. Comprenderlo es fundamental para apreciar la elegancia de la solución N+M que ofrece el protocolo.

Complejidad combinatoria, crecimiento exponencial, N×M vs. N+M, escalabilidad, mantenimiento.

La fragmentación de las integraciones genera costos enormes: tiempo de desarrollo desperdiciado al recrear soluciones, dinero gastado en mantener código duplicado y una complejidad creciente que dificulta la evolución de los sistemas.

Cuantificar los costos de la fragmentación ayuda a justificar la adopción de MCP en cualquier organización. Ese es el argumento de negocio detrás de la decisión técnica.

Costo de mantenimiento, deuda técnica, tiempo de salida al mercado, duplicación de esfuerzos, escalabilidad organizacional.

Antes de MCP, varios enfoques intentaron resolver el problema de las integraciones: APIs REST genéricas, SDKs específicos de cada plataforma, plugins propietarios como los de ChatGPT y frameworks de function calling. Cada uno resolvió parte del problema, pero creó otros nuevos.

Conocer los intentos anteriores muestra por qué no lograron ser universales y cómo el MCP aprendió de cada uno para crear algo mejor.

APIs REST, SDKs, plugins, function calling, dependencia de plataforma, interoperabilidad.

Así como USB estandarizó las conexiones físicas y HTTP estandarizó la web, la integración de la IA con herramientas externas necesitaba un protocolo universal. La necesidad de un estándar abierto, extensible e independiente de la plataforma era inevitable.

Entender por qué un estándar era inevitable ayuda a ver MCP no como una tecnología pasajera, sino como una pieza fundamental de la infraestructura de IA del futuro.

Protocolo abierto, estandarización, interoperabilidad, efecto de red, ecosistema, adopción universal.

Model Context Protocol (MCP) es un protocolo abierto que estandariza cómo se comunican los modelos de IA con herramientas, datos y servicios externos. Define una interfaz universal que cualquier modelo puede usar para acceder a cualquier herramienta compatible.

Esta es la definición fundamental de lo que vas a construir a lo largo del curso. Tener claro qué es MCP garantiza que entiendas cada concepto posterior.

Model Context Protocol, protocolo abierto, interfaz universal, estandarización de integraciones, JSON-RPC.

Así como USB creó un conector universal para los dispositivos físicos, MCP crea un «conector universal» para las integraciones de IA. Antes de USB, cada fabricante tenía su propio cable. MCP hace lo mismo para el mundo de los modelos de lenguaje.

La analogía del USB es la forma más intuitiva de explicar MCP a cualquier persona. Dominarla te permite comunicar el valor del protocolo a desarrolladores y a quienes no lo son.

Analogía con USB, conector universal, plug-and-play, compatibilidad, ecosistema abierto.

MCP fue creado por Anthropic, la empresa detrás de Claude. La motivación surgió de la necesidad de permitir que Claude y otros modelos se conectaran a herramientas externas de forma segura, estandarizada y extensible, sin depender de soluciones propietarias.

Conocer el origen y la motivación del MCP ayuda a entender sus decisiones de diseño y por qué es un protocolo abierto, no un producto propietario.

Anthropic, protocolo abierto, open source, diseño centrado en la seguridad, extensibilidad.

MCP transforma el problema N×M en N+M. En vez de que cada modelo necesite una integración específica para cada herramienta, cada modelo implementa MCP una vez y cada herramienta implementa MCP una vez. Todos se conectan automáticamente.

Esta es la propuesta de valor central de MCP. Entender la transformación de N×M a N+M es esencial para comunicar por qué importa el protocolo.

N+M vs N×M, reducción de la complejidad, interfaz estandarizada, reutilización, composabilidad.

El ecosistema MCP está creciendo rápidamente. Empresas como Anthropic, herramientas como Cursor y Windsurf, y diversos proyectos open source ya adoptaron el protocolo. La cantidad de MCP Servers disponibles crece cada semana.

Saber quién está adoptando MCP valida la tecnología y muestra que no es solo una especificación teórica: es una realidad en producción.

Ecosistema MCP, adopción empresarial, Cursor, Claude Desktop, MCP Servers, comunidad open source.

MCP avanza para convertirse en el estándar de facto para las integraciones de IA. El roadmap del protocolo incluye nuevas capacidades, como autenticación nativa, un marketplace de servers e integración con agentes autónomos.

Entender el futuro de MCP te posiciona como early adopter. Quienes dominen el protocolo ahora estarán preparados para las oportunidades que surgirán con su adopción masiva.

Roadmap de MCP, marketplace de servers, autenticación, agentes autónomos, estándar de facto, evolución del protocolo.

El Host es la aplicación que aloja el modelo de IA, como Claude Desktop, Cursor o cualquier IDE que integre un LLM. Es el entorno donde interactúas y desde donde se originan las solicitudes de herramientas.

Entender el papel del Host es fundamental para saber dónde encaja MCP en el stack. Todo flujo de MCP comienza y termina en el Host.

Aplicación host, entorno de ejecución, Claude Desktop, Cursor, interfaz de usuario, ciclo de vida.

El Client es el componente dentro del Host que administra la comunicación con los MCP Servers. Envía solicitudes, recibe respuestas y traduce entre el formato del modelo y el protocolo MCP. Cada conexión a un Server tiene su propio Client.

El Client es el intermediario que hace que todo funcione. Entender su función te ayuda a depurar problemas y crear integraciones más sólidas.

MCP Client, intermediario, gestión de conexión, traducción de protocolo, sesión, estado.

El Server es el componente que expone herramientas, datos y prompts al modelo de IA. Implementa el protocolo MCP y responde a las solicitudes del Client. Es lo que vas a crear en este curso.

El Server es el protagonista de este curso. Todo lo que aprendas aquí te prepara para crear tus propios MCP Servers que amplíen las capacidades de cualquier modelo de IA.

MCP Server, exposición de herramientas, recursos, prompts, implementación de protocolo, endpoints.

El flujo completo de MCP sigue este recorrido: Usuario → Host → Client → Server → Herramienta → Server → Client → Host → Usuario. Cada etapa cumple una función específica y el protocolo garantiza que la comunicación esté estandarizada en todo el recorrido.

Visualizar el flujo completo de extremo a extremo es esencial para depurar, optimizar y crear integraciones que funcionen correctamente en producción.

Flujo de solicitudes, ciclo request-response, pipeline de comunicación, encadenamiento de componentes.

Un diagrama mental de la arquitectura MCP muestra visualmente cómo se relacionan Host, Client y Server. El Host contiene uno o más Clients, cada Client se conecta a exactamente un Server y cada Server puede exponer múltiples tools, resources y prompts.

Tener un modelo mental claro de la arquitectura te permite razonar sobre problemas complejos y diseñar soluciones elegantes.

Diagrama de arquitectura, relación 1:N, modelo mental, composición de componentes, visión sistémica.

Ejemplos prácticos de arquitecturas MCP en el mundo real: Claude Desktop (Host) usa un filesystem server para acceder a archivos, Cursor (Host) usa un database server para consultar bases de datos y aplicaciones personalizadas usan varios servers simultáneamente.

Ver ejemplos concretos transforma conceptos abstractos en conocimiento práctico. Reconocerás patrones que usarás en tus propios proyectos.

Filesystem server, database server, GitHub server, configuración multiservidor, escenarios de producción.

Claude Desktop es la aplicación oficial de Anthropic que sirve como Host para Claude. Es compatible con MCP de forma nativa, lo que te permite conectar herramientas externas al modelo sin tener que escribir código de integración.

Claude Desktop será tu entorno de pruebas durante todo el curso. Instalarlo y configurarlo correctamente es el primer paso práctico para usar MCP.

Claude Desktop, instalación, plataformas compatibles, versión mínima, requisitos del sistema.

claude_desktop_config.json es el archivo donde indicas qué MCP Servers debe iniciar Claude Desktop. Cada entrada define el comando para ejecutar el server, sus argumentos y variables de entorno.

Este archivo es la puerta de entrada para cualquier integración MCP en Claude Desktop. Lo editarás con frecuencia a lo largo del curso para agregar nuevos servers.

claude_desktop_config.json, mcpServers, command, args, env, ubicación del archivo.

El filesystem server es un MCP Server oficial que permite a Claude acceder a archivos y directorios de tu computadora. Conectarlo es tan sencillo como agregar unas líneas al archivo de configuración.

Este es tu primer contacto real con un MCP Server en funcionamiento. Ver a Claude acceder a tus archivos es el momento «¡ajá!» que consolida la comprensión del protocolo.

@modelcontextprotocol/server-filesystem, npx, directorios permitidos, permisos, sandboxing.

Después de configurar el filesystem server, debes verificar que la conexión funcione. Claude Desktop muestra indicadores visuales de los servers conectados y puedes probar enviando mensajes que requieran acceso a archivos.

Saber validar una conexión MCP es una habilidad fundamental de debugging. Cuando algo falle en tus propios servers, sabrás cómo diagnosticarlo.

Comprobación de la conexión, indicadores visuales, logs de errores, troubleshooting y handshake MCP.

Con el filesystem server conectado, puedes pedirle a Claude que liste archivos, lea contenido, cree directorios y más. El modelo identifica automáticamente cuándo necesita usar una tool y solicita permiso al usuario.

Usar tools en la práctica muestra el verdadero poder de MCP. Verás cómo el modelo decide cuándo y cómo usar herramientas, incluido el mecanismo de permisos del usuario.

Llamada a tools, aprobación del usuario, read_file, list_directory, write_file, flujo de uso de tools.

Detrás de cada interacción con el filesystem server, ocurre un flujo completo de JSON-RPC: Claude identifica la necesidad de una tool, el Client envía la solicitud al Server, el Server ejecuta la acción y devuelve el resultado, que se incorpora a la respuesta del modelo.

Entender lo que ocurre detrás de la interfaz es lo que distingue a un usuario de un desarrollador. Este conocimiento es esencial para crear tus propios MCP Servers.

JSON-RPC, mensajes de protocolo, initialize, tools/list, tools/call, request-response cycle.

Las tools son funciones que el modelo puede llamar para ejecutar acciones, como leer un archivo, consultar la base de datos o enviar un correo electrónico. Reciben parámetros y devuelven resultados, de forma similar a las llamadas a funciones.

Las tools son el recurso más usado de MCP. La mayoría de los servers que crearás exponen tools. Entender sus características es fundamental para diseñar interfaces eficaces.

Definición de tool, esquema de entrada, formato de salida, llamada a tools, efectos secundarios, idempotencia.

Los Resources son datos estáticos o dinámicos a los que el modelo puede acceder para enriquecer su contexto, como documentos, configuraciones, logs o datos de una API. A diferencia de las tools, los Resources son pasivos: proporcionan información sin ejecutar acciones.

Los Resources te permiten proporcionar contexto enriquecido al modelo sin necesidad de tool calls. Son ideales para datos que el modelo necesita consultar con frecuencia.

Resource URI, MIME type, contenido estático vs. dinámico, resource templates, lectura bajo demanda.

Los prompts son plantillas de instrucciones que el Server puede ofrecer al Host. Permiten crear workflows predefinidos, con argumentos parametrizables, que guían al modelo para realizar tareas complejas de forma coherente.

Los prompts son el recurso menos aprovechado de MCP, pero ofrecen un enorme potencial. Permiten crear experiencias guiadas que transforman el modelo en un asistente especializado.

Plantilla de prompt, argumentos, mensajes predefinidos, workflows, personalización, coherencia.

Las tools ejecutan acciones, los Resources proporcionan datos y los Prompts guían el comportamiento. La elección entre ellos depende de si quieres que el modelo haga algo (tool), sepa algo (resource) o siga un patrón (prompt).

Elegir el tipo de recurso adecuado para cada situación es una decisión de diseño fundamental. Usar el tipo incorrecto da lugar a experiencias confusas e ineficientes.

Acción vs. dato vs. instrucción, decisión de diseño, controlado por el modelo vs. controlado por el usuario, efectos secundarios.

Ejemplos reales de los tres tipos: una tool que crea issues en GitHub, un resource que expone la documentación de la API y un prompt que guía al modelo para hacer code review siguiendo estándares específicos de la empresa.

Los ejemplos concretos consolidan la comprensión teórica e inspiran ideas para tus propios servers. Empezarás a ver oportunidades de MCP en todos tus proyectos.

Herramientas de GitHub, documentación como resource, prompts para revisión de código, automatización de workflows, escenarios de negocio.

El verdadero poder de MCP aparece cuando combinas tools, resources y prompts en un mismo server. Por ejemplo: un resource proporciona contexto, un prompt guía el razonamiento y una tool ejecuta la acción resultante; todo orquestado por el modelo.

Combinar los tres tipos de recursos es clave para crear MCP Servers sofisticados que ofrecen experiencias ricas y completas a los modelos de IA.

Composición de recursos, diseño de server, experiencia integrada, orquestación por el modelo, patrones de diseño.

Los transportes son los mecanismos que definen cómo viajan los mensajes MCP entre el Client y el Server. Son la capa de comunicación del protocolo, responsable de enviar y recibir mensajes JSON-RPC de forma confiable.

Elegir el transporte adecuado influye en el rendimiento, la seguridad y la arquitectura de tu solución. Es una decisión fundamental en el diseño de cualquier MCP Server.

Capa de transporte, JSON-RPC, mecanismo de comunicación, confiabilidad, latencia.

STDIO (Standard Input/Output) es el transporte más sencillo de MCP. El Client inicia el Server como un proceso hijo y se comunica mediante stdin y stdout. Es ideal para servers que se ejecutan localmente en la misma máquina que el Host.

STDIO es el transporte que usarás durante la mayor parte del curso. Es simple, confiable y no requiere configuración de red. La mayoría de los servers de desarrollo usan STDIO.

stdin, stdout, proceso hijo, comunicación local, simplicidad, sin red.

El transporte HTTP permite que el MCP Server funcione como un servicio web accesible de forma remota. El Client envía solicitudes HTTP POST con mensajes JSON-RPC y recibe respuestas. Es ideal para servers a los que deben acceder varios clients o que deben funcionar en servidores remotos.

HTTP es el transporte que se usa en entornos de producción y para servers compartidos. Entenderlo te prepara para hacer deploy de MCP Servers que atienden a múltiples usuarios.

HTTP POST, endpoints, servidor web, autenticación, CORS, deployment remoto.

Server-Sent Events (SSE) es un transporte que permite el streaming unidireccional del Server al Client. Combinado con HTTP POST para enviar mensajes al Server, crea un canal de comunicación bidireccional ideal para operaciones de larga duración y notificaciones en tiempo real.

SSE es importante en situaciones que requieren comentarios en tiempo real, como el monitoreo de procesos largos o el streaming de resultados parciales.

Server-Sent Events, streaming, EventSource, conexión persistente, notificaciones push, tiempo real.

Cada transporte tiene sus ventajas y desventajas: STDIO es el más simple, pero solo funciona localmente. HTTP es versátil y funciona de forma remota, pero no admite streaming nativo. SSE agrega streaming, pero requiere más infraestructura. La elección depende del escenario de uso.

Comparar transportes te da criterios claros para tomar decisiones de arquitectura. Sabrás justificar la elección del transporte en cualquier proyecto.

Compromisos, latencia frente a simplicidad, local frente a remoto, escalabilidad, requisitos de infraestructura.

Una guía práctica para elegir el transporte: usa STDIO para desarrollo y servers personales, HTTP para producción y servers compartidos, y SSE cuando necesites streaming o notificaciones en tiempo real. Considera también la seguridad, la complejidad y el mantenimiento.

Tener un marco de decisión claro ahorra tiempo y evita refactorizaciones futuras. Sabrás elegir el transporte adecuado desde el inicio de cada proyecto.

Marco de decisión, escenarios de uso, desarrollo vs. producción, checklist de requisitos, migración entre transportes.