Cómo funciona MCP, el protocolo que conecta LLMs con datos reales
MCP es un protocolo abierto que estandariza cómo una app le da contexto y herramientas a un LLM, en vez de que cada integración sea un adaptador a medida. Sirve para que un agente use tus archivos, tu base de datos o tu Git sin que tengas que inventar una API nueva cada vez.
El problema que MCP viene a resolver
Un LLM entrenado hace meses no sabe nada de lo que pasó después, y tampoco conoce el catálogo interno de tu empresa ni tus procesos propios. La solución típica hasta ahora era construir integraciones ad hoc: un conector para RAG, otro para buscar en una base de datos, otro para pegarle a un CRM, cada uno con su propia lógica. El costo de eso no es solo el tiempo de desarrollo, es que cada integración queda pegada a un modelo específico, y si mañana querés cambiar de proveedor de LLM tenés que reescribir todo. MCP propone lo mismo que hizo HTTP para la web: un protocolo único para que cualquier aplicación le pase contexto a cualquier modelo, sin acoplarte a una implementación particular.
La arquitectura cliente-servidor detrás de MCP
MCP separa claramente dos roles: el servidor, que expone datos y capacidades (un sistema de archivos, una base de datos, un repositorio Git), y el cliente, que vive dentro de la aplicación que usa el LLM y consume esas capacidades. El modelo nunca habla directo con tu infraestructura; habla con el cliente MCP, y el cliente MCP habla con el servidor MCP siguiendo el protocolo. Esta separación es la que te permite tener diez servidores distintos conectados a la vez sin que el código de cada uno sepa nada del otro. También es la razón por la que podés cambiar de LLM sin tocar tus servidores: el contrato está en el protocolo, no en el modelo.
Tools, Resources y Prompts: lo que expone un servidor
Del lado del servidor, MCP define tres tipos de capacidades que podés exponer. Tools son funciones que el modelo puede invocar para hacer algo (leer un archivo, correr una query, crear un issue). Resources son datos que el servidor pone a disposición para que el cliente los inyecte como contexto, sin que necesariamente el modelo tenga que pedirlos explícitamente. Prompts son plantillas reutilizables que el servidor ofrece para guiar interacciones comunes. La razón de separarlos así es que no todo lo que necesita un agente es una acción: a veces necesitás datos de fondo, y a veces necesitás una plantilla probada en vez de reinventar el prompt cada vez.
Roots y Sampling: lo que aporta el cliente
Del lado del cliente, MCP define Roots, que le dicen al servidor a qué directorios o URIs tiene permiso de acceder, y Sampling, que le permite al servidor pedirle al cliente que genere una completion usando el LLM que el cliente tiene configurado. Esto invierte el flujo habitual: en vez de que el servidor tenga su propia clave de API y su propio modelo, delega esa responsabilidad en el cliente. Es una decisión de diseño importante para seguridad y costos, porque el servidor nunca maneja credenciales de LLM ni decide qué modelo se usa; eso queda del lado de quien controla la aplicación final.
Transports: cómo se hablan cliente y servidor
El protocolo base de MCP no asume un único medio de transporte; define mensajes y un ciclo de vida (lifecycle), y después especifica distintos transports para llevar esos mensajes de un lado a otro. Esto importa en la práctica porque un servidor MCP que corre como proceso local en tu máquina no tiene los mismos requisitos que uno que corre remoto y necesita autenticación. Elegir el transport correcto es parte del diseño de tu servidor, no un detalle de implementación que podés ignorar hasta el final.
Un ecosistema de servidores que ya existen
No todo hay que construirlo de cero: ya existen servidores MCP para sistemas de archivos, bases de datos como PostgreSQL y SQLite, herramientas de desarrollo como Git, GitHub y GitLab, búsqueda web, y herramientas de productividad como Slack o Google Maps. Esto cambia la pregunta de 'cómo integro esto' a 'qué servidor ya existe para esto', y te deja el tiempo de desarrollo para las integraciones que sí son específicas de tu dominio. Un buen punto de partida para un proyecto propio suele ser mirar qué servidor existente se parece más a lo que necesitás, y a partir de ahí decidir si lo usás tal cual o escribís el tuyo.
Qué puedes construir con esto
Tres proyectos que se hacen en una tarde y terminan en algo que corre.
Servidor MCP de solo lectura sobre una carpeta de proyecto
Un servidor MCP propio que expone como Tools operaciones puntuales sobre una carpeta específica (listar archivos, leer contenido) usando Roots para limitar el acceso a ese directorio.
Servidor MCP sobre una base de datos SQLite
Un servidor que expone un conjunto acotado de queries como Tools, de forma que el modelo pueda responder preguntas sobre datos reales sin que vos escribas un pipeline de RAG completo.
Cliente MCP que combina dos servidores a la vez
Un cliente propio que se conecta simultáneamente a un servidor de filesystem y a un servidor de Git, y usa Sampling para pedirle al LLM que redacte mensajes de commit basados en los cambios detectados.
Qué te llevas
MCP separa el rol de servidor (expone Tools, Resources, Prompts) del rol de cliente (maneja Roots y Sampling), y esa separación es lo que te permite cambiar de LLM sin tocar tus integraciones.
El servidor nunca tiene su propia clave de LLM: cuando necesita generar texto, le pide al cliente que use Sampling, así las credenciales del modelo quedan en un solo lugar.
Antes de escribir un servidor desde cero, conviene revisar el ecosistema existente (filesystem, Git, Postgres, Slack) porque buena parte de las integraciones comunes ya están resueltas.
El protocolo no fuerza un transporte único, así que el diseño de cómo se conectan tu cliente y tu servidor es una decisión temprana, no un detalle de infraestructura.