15 de mayo de 2026 · 11 min de lectura

Qué es Model Context Protocol (MCP): guía técnica práctica para developers en 2026

Si construís con modelos de lenguaje y todavía estás escribiendo conectores custom para cada API que tu agente necesita consultar, el Model Context Protocol (MCP) cambia el problema. Esta es la lectura técnica que escribí después de construir un servidor MCP en producción para tramites.gub.uy.

El problema que resuelve MCP

Hasta 2024, conectar un LLM a sistemas externos (bases de datos, APIs internas, herramientas, archivos) implicaba uno de estos caminos:

  • Function calling propietario — cada proveedor (OpenAI, Anthropic, Google) tenía su propio formato para describir herramientas. Cambiar de modelo significaba reescribir conectores.
  • Frameworks como LangChain o LlamaIndex — abstraían la diferencia, pero al costo de capa de abstracción adicional, dependencias y un patrón de extensibilidad propio.
  • Conectores custom por aplicación — un endpoint REST por cada cosa que el agente necesita hacer, con el modelo orquestando llamadas vía prompt engineering.

Ninguno escala bien cuando tu agente necesita acceso a 10, 50 o 200 sistemas distintos. Y ninguno es portable: si construís integraciones para Claude, no podés reusarlas con ChatGPT sin reescribir.

Qué es Model Context Protocol

MCP es un protocolo abierto que estandariza cómo los modelos de lenguaje se conectan con sistemas externos. Lo lanzó Anthropic en noviembre de 2024 y rápidamente fue adoptado por otros vendors y herramientas: hoy es soportado por Claude Desktop, Claude Code, Cursor, n8n, ChatGPT (vía custom connectors), y cientos de servidores MCP open source publicados en directorios como mcp.so o el oficial de Anthropic.

La analogía más útil: MCP es a los agentes de IA lo que USB es a los periféricos. Antes de USB, cada teclado, mouse y impresora tenía su puerto propio. Después: un estándar, mil dispositivos compatibles. Lo mismo está pasando con MCP y las integraciones de LLMs.

Componentes del protocolo

MCP define tres conceptos primarios que un servidor expone:

1. Tools

Acciones que el modelo puede invocar. Cada tool tiene un nombre, una descripción en lenguaje natural, un schema de inputs y un handler que ejecuta la lógica. Ejemplo de mi servidor MCP de trámites: 

search_uruguay_government_procedures(query, organismo?, limit?)
get_uruguay_government_procedure(id)
list_uruguay_government_organismos()

El modelo decide cuándo llamarlas en función del prompt del usuario y de la descripción de cada tool.

2. Resources

Datos que el modelo puede leer (archivos, registros de base de datos, contenido remoto). Se identifican con URIs custom, como tramite://606 o file:///path/to/doc.pdf. La diferencia con tools: resources son lectura pasiva, tools son acciones.

3. Prompts

Plantillas de prompt reusables que el cliente MCP puede ofrecer al usuario. Útil para flujos repetitivos donde querés guiar al modelo con un prompt específico que el usuario no necesita escribir cada vez.

Arquitectura: cliente, servidor y transporte

Un sistema MCP tiene tres piezas:

  • Cliente MCP: la aplicación que usa el modelo (Claude Desktop, Claude Code, Cursor, ChatGPT). Decide qué servidores conectar y orquesta las llamadas.
  • Servidor MCP: tu integración. Expone tools, resources y prompts. Puede estar escrito en cualquier lenguaje que tenga un SDK MCP disponible (Python, TypeScript, Go, Rust, Java, C#).
  • Transporte: cómo se comunican cliente y servidor.

Transportes disponibles

  • stdio: el cliente lanza el servidor como subproceso local y se comunica vía stdin/stdout. Ideal para herramientas que corren en la máquina del usuario (acceso a archivos locales, comandos del sistema).
  • HTTP Streamable: el servidor corre como servicio HTTP, accesible vía URL pública. El cliente se conecta por HTTP con eventos en streaming. Es el transporte que usé para el MCP de trámites — necesario para servidores compartidos por múltiples usuarios y deploys en infra cloud.

El cambio importante de 2025: el viejo transporte SSE (Server-Sent Events) fue deprecated en favor de HTTP Streamable. Si estás empezando hoy, ignorá los tutoriales viejos que mencionan SSE.

Cómo se compara MCP con alternativas

vs REST APIs tradicionales

Una API REST funciona perfectamente — pero el modelo necesita prompt engineering para saber cuándo llamar qué endpoint y cómo armar los parámetros. Con MCP, las descripciones de tools están estandarizadas y el cliente las inyecta automáticamente al contexto del modelo. Menos prompt engineering, menos errores.

vs Function calling propietario

Function calling de OpenAI o Anthropic resuelve el problema de "cómo le digo al modelo qué herramientas tiene", pero cada vendor tiene su propio formato. MCP es agnóstico: tu servidor funciona con cualquier cliente MCP-compliant.

vs RAG

RAG (Retrieval-Augmented Generation) es para consultar grandes corpus de documentos. MCP es para acciones y consultas estructuradas. No son alternativas — son complementarios. Un servidor MCP puede usar RAG internamente para responder mejor a sus tools.

vs LangChain / LlamaIndex

Frameworks como LangChain ofrecen abstracciones de orquestación, memoria, agentes y RAG. MCP no compite con eso: MCP es solo el protocolo de conexión modelo-herramienta. Podés usar LangChain con servidores MCP perfectamente, e incluso es probable que termines haciéndolo en proyectos no triviales.

Cuándo SÍ usar MCP

  1. Tenés varios clientes consumiendo las mismas integraciones. Si construís un servidor MCP para tu API interna, lo pueden usar Claude Desktop, Claude Code, Cursor, n8n y ChatGPT sin reescribir.
  2. Querés que tus integraciones sobrevivan al cambio de modelo. Si pasás de Claude a GPT-5 (o viceversa), tu servidor MCP no cambia.
  3. Estás construyendo un agente complejo con muchas herramientas. La estandarización paga su costo.
  4. Querés exponer tu producto a usuarios de IA. Tener un servidor MCP público es un nuevo "tener una API" — los usuarios pueden conectarlo a sus agentes en segundos.
  5. Trabajás en proyectos open source. La comunidad MCP es la pieza más activa del ecosistema de IA en 2026 después de los modelos mismos.

Cuándo NO usar MCP

  1. Una integración chica, una sola aplicación. Si tu LLM solo necesita un endpoint REST y no vas a reusar la integración, MCP es overhead innecesario.
  2. Latencia ultrabaja. MCP agrega capas de protocolo. Si necesitás respuestas en menos de 100ms, una llamada directa es mejor.
  3. Sistemas legacy donde no podés agregar dependencias. Si tu stack es antiguo o restringido, exponer un servidor MCP puede ser más complejo que un endpoint custom.

Stack actual: clientes y servidores

Clientes MCP populares

  • Claude Desktop — cliente de referencia de Anthropic. Configuración vía archivo JSON.
  • Claude Code — CLI de developer. claude mcp add --transport http my-server https://....
  • ChatGPT (custom connectors) — soporte de MCP vía custom connectors desde 2025.
  • Cursor — editor con soporte nativo de MCP.
  • n8n — automatización con nodos MCP para flujos sin código.

Servidores MCP de referencia

Anthropic mantiene servidores oficiales para GitHub, Slack, Google Drive, Postgres, Filesystem y otros. La comunidad publicó cientos más en directorios como mcp.so o el de Smithery. Si necesitás conectar tu agente a un sistema común, alta probabilidad que ya exista un servidor MCP.

SDKs disponibles

  • Python: mcp (SDK oficial) — el más maduro y completo.
  • TypeScript: @modelcontextprotocol/sdk — soportado oficialmente.
  • Go: mcp-go de mark3labs — el que usé para el MCP de trámites. Maduro y bien mantenido.
  • Rust, Java, C#, Kotlin: SDKs comunitarios o oficiales según el caso.

Casos de uso reales en producción

Más allá del hype, casos donde MCP está corriendo en serio:

  • Asistentes internos para empresas: conectan el LLM al ERP, CRM, BI y sistemas de tickets.
  • Agentes de operaciones DevOps: el LLM consulta logs, métricas, repos y tickets a través de servidores MCP especializados.
  • Asistentes de gobierno digital: como mi MCP de tramites.gub.uy que permite a agentes de IA consultar datos oficiales de trámites del Estado uruguayo con fuentes verificables.
  • IDEs aumentados: Claude Code y Cursor usan MCP para que el modelo acceda a tu código, repo, y herramientas de testing.
  • Workflows de investigación: agentes que combinan acceso a búsqueda web, papers académicos, y bases de conocimiento internas.

Cómo arrancar

Si nunca construiste un servidor MCP, el camino más corto:

  1. Elegí un caso chico y verificable. "Mi agente puede consultar mi BD interna" es un buen primer caso.
  2. Empezá con SDK de Python o TypeScript usando transporte stdio. Es lo más rápido para iterar.
  3. Conectalo a Claude Desktop o Claude Code y validá que el flujo funciona end-to-end.
  4. Si vas a producción multi-usuario, migrá a HTTP Streamable y deployá vía Docker. Tengo un post detallado sobre esto: Cómo desplegar un servidor MCP en Docker y Dokploy.

Referencia: mi servidor MCP de tramites.gub.uy

Si querés ver código real en producción, github.com/fabdelgado/mcp-tramites-gub-uy. Servidor en Go, transporte HTTP Streamable, búsqueda híbrida (FTS5 + embeddings), deploy con Docker Compose y Dokploy. La historia completa del proyecto está en el blog.

Preguntas frecuentes

¿MCP es compatible con todos los modelos de IA?

Con cualquier modelo que tenga un cliente MCP que lo use. Hoy: Claude (todas las variantes), GPT (vía ChatGPT custom connectors), Gemini (vía Cursor o herramientas de terceros), modelos abiertos (vía Continue, n8n, frameworks). El protocolo es agnóstico al modelo.

¿Necesito cambiar mi API existente para soportar MCP?

No. Tu API queda como está. El servidor MCP es una capa adicional que traduce calls MCP a calls a tu API. Podés correrlo en el mismo proceso o como microservicio aparte.

¿Cómo se autentica un cliente MCP a un servidor remoto?

MCP soporta varios mecanismos: API keys vía headers HTTP, OAuth, mTLS. Para servidores públicos en producción, OAuth o API keys son lo más común. Para servidores internos, mTLS o autenticación a nivel red.

¿Hay riesgo de seguridad si expongo un servidor MCP a internet?

Sí, los mismos que con cualquier API pública: rate limiting, autenticación, autorización por tool, sanitización de inputs, logs de auditoría. Mi post sobre deploy cubre el hardening mínimo.

¿MCP reemplaza a function calling de OpenAI o Anthropic?

No los reemplaza, los complementa. Bajo el capó, cuando un cliente MCP llama una tool, termina invocando function calling del modelo. MCP es la capa de transporte y descubrimiento; function calling es cómo el modelo decide llamar la tool.

¿Tu organización necesita conectar IA a sus sistemas existentes vía MCP? Construyo servidores MCP a medida para empresas y organismos. Ver servicios · Conversemos un proyecto.

Continuación práctica: Cómo desplegar un servidor MCP en Docker y Dokploy. Ejemplo en producción: Cómo construí un MCP para tramites.gub.uy.