MCP (Model Context Protocol) en 2026: guía completa para equipos técnicos

MCP, abreviatura de Model Context Protocol, es el estándar abierto que en 2026 conecta cualquier modelo (Claude, GPT, Gemini) con cualquier herramienta o fuente de datos sin contrato propietario por medio. Este artículo cubre lo que necesita un equipo técnico para adoptarlo bien: cómo encaja la arquitectura cliente-servidor, qué servidores conviene usar y cuáles construir, cómo aislar credenciales fuera del modelo, cómo componer varios servidores con prefijos de herramienta y qué antipatrones ya se cobran víctimas en producción. Ver también: MCP como estándar multi-vendor: patrones ya maduros.

Puntos clave

• MCP es ya el estándar de hecho para conectar modelos a herramientas: propuesto por Anthropic en noviembre de 2024 y adoptado en 2025-2026 por OpenAI, Google, Cursor, Claude Code y VS Code.
• La arquitectura es de tres roles: cliente LLM, servidor MCP que expone herramientas, recursos y prompts, y orquestador que aplica política y prefijos.
• Combina servidores comunitarios (server-filesystem, server-postgres, server-github) para capacidades genéricas con servidores propios para la lógica de dominio. No mezclar nunca los dos.
• Las credenciales viven en el servidor, no en el prompt ni en el modelo. Variables de entorno al arrancar el servidor o cabeceras Authorization en el descriptor.
• La composición multi-servidor se hace con prefijos (fs:read_file, db:query) para evitar colisiones de nombres; el orquestador resuelve, el modelo elige herramienta.
• Los antipatrones ya documentados van todos en la misma dirección: dar al modelo más capacidades de las que justifica la política.

Qué es MCP y por qué se ha convertido en estándar

MCP^[1] es un protocolo abierto que estandariza cómo una aplicación que aloja un modelo —un editor, un agente, un asistente de chat— descubre y llama herramientas externas, lee recursos y dispara prompts predefinidos. Antes de MCP, cada vendor tenía su propio mecanismo: function-calling propietario en OpenAI, tool use en Anthropic, plugins en ChatGPT, ext en Cursor. Cada integración había que reescribirla por triplicado y cualquier cambio rompía contratos en cuatro sitios.

Anthropic propuso MCP en noviembre de 2024 con una idea sencilla: si el modelo y la herramienta hablan un protocolo común basado en JSON-RPC, el integrador escribe el servidor una vez y cualquier cliente compatible lo consume. La analogía oficial, “USB-C para aplicaciones de IA”, es algo simplista pero captura la intuición correcta: estandarizar el conector libera el ecosistema.

Lo que ha pasado en los dieciocho meses siguientes es lo que justifica considerarlo estándar. Durante 2025 y 2026, OpenAI, Google, Cursor, Claude Code, Visual Studio Code, MCPJam y cientos de herramientas comunitarias han añadido soporte nativo para MCP, según el directorio público en modelcontextprotocol.io^[1]. El resultado es un ecosistema en el que un servidor MCP escrito para Claude funciona en ChatGPT, en Cursor y en VS Code sin cambios; un servidor MCP de GitHub o de Postgres está disponible para todos los clientes a la vez.

La consecuencia operativa es la que importa: las integraciones dejan de ser activos atados a un proveedor concreto y pasan a ser activos del propio equipo, portables. Si decides cambiar de modelo —porque ha salido uno mejor, porque el precio se ha disparado, porque la latencia no encaja— tus servidores MCP siguen funcionando igual. Esa portabilidad real es la razón por la que en 2026 cualquier arquitectura nueva de agentes empieza por MCP, no por un mecanismo propietario.

Arquitectura: clientes, servidores y orquestador

El modelo mental son tres roles. El cliente LLM es la aplicación que ejecuta el modelo y orquesta la conversación: Claude Desktop, Cursor, una app que use el SDK de Anthropic. El servidor MCP es un proceso (o endpoint HTTP) que expone capacidades en tres formas: tools (acciones que el modelo puede invocar), resources (datos que el modelo puede leer) y prompts (plantillas predefinidas). El orquestador vive dentro del cliente y se encarga de descubrir servidores, aplicar política, presentar las herramientas al modelo con prefijos y traducir las llamadas del modelo a invocaciones JSON-RPC sobre el transporte adecuado.

Los transportes que importan en 2026 son tres: stdio para servidores locales que se lanzan como subproceso, HTTP (con o sin SSE) para servidores remotos, y SDK in-process para herramientas definidas en el mismo binario que el cliente. La elección depende de quién posee el ciclo de vida del proceso. Servidores genéricos comunitarios suelen ser stdio (npx/uvx lanza el binario al arrancar el cliente). Servicios remotos —un MCP de tu CRM SaaS, una integración con un proveedor— son HTTP. Herramientas custom muy ligadas al producto se montan in-process para evitar overhead de IPC.

Un descriptor mínimo en formato .mcp.json ilustra la pieza más simple:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/srv/data"],
      "env": {
        "FS_READ_ONLY": "true"
      }
    }
  }
}

El cliente lee este fichero al arrancar, lanza el subproceso npx, intercambia el handshake MCP, descubre las herramientas disponibles (read_file, list_directory, etc.) y las presenta al modelo con el prefijo mcp__filesystem__*. El diagrama de cabecera muestra la versión multi-servidor de esta arquitectura, con tres servidores conectados al orquestador y cada uno con sus credenciales y su política aisladas.

La pieza de observabilidad del estándar también está cuajada: la especificación GenAI de OpenTelemetry^[2] incluye desde finales de 2025 atributos específicos para MCP (mcp.method.name, mcp.protocol.version, mcp.session.id) que cualquier servidor o cliente puede emitir como spans. En la práctica, esto significa que los traces de tus llamadas MCP se cruzan en Grafana o Honeycomb con el resto de la traza del agente sin instrumentación ad hoc. Quien haya pasado por la era de instrumentar function-calling propietario sabe lo que esto vale.

Servidores genéricos vs servidores propios

El patrón que ha ganado en 2026 es doble pila: servidores comunitarios genéricos para capacidades horizontales, servidores propios para la lógica vertical de tu producto. Mezclar los dos —parchear un servidor comunitario para añadirle un endpoint de tu CRM— es el error que más rupturas silenciosas produce.

Los servidores comunitarios que casi todo el mundo acaba usando son un puñado bien conocido. npx -y @modelcontextprotocol/server-filesystem /ruta da acceso al sistema de ficheros con read_file, write_file, list_directory. npx -y @modelcontextprotocol/server-github expone issues, PRs y búsquedas, autenticado con GITHUB_TOKEN. npx -y @modelcontextprotocol/server-postgres "$DATABASE_URL" da una herramienta query parametrizable contra la base. uvx mcp-server-git lanza el equivalente Python. Hay decenas más en el directorio oficial y la lista crece todos los meses.

Los servidores propios cumplen otro papel. Si tu producto tiene un dominio —un CRM, un PIM, una plataforma de logística— y quieres que el agente actúe sobre él, el servidor MCP es donde vive esa lógica. Lo construyes con el SDK oficial (TypeScript o Python son los más maduros), lo versionas junto al producto, y le pones tests de contrato como a cualquier API interna. La gran diferencia con un servidor comunitario es que tú controlas el binario: la rotación de credenciales, el versionado y la política de cambios la decides tú.

La regla operativa para decidir qué va en cada lado es bastante limpia. Si la capacidad existe en la lista comunitaria y se ajusta razonablemente, úsala. Te ahorras código, mantenimiento y, sobre todo, te ahorras la tentación de meter dominio en una pieza genérica. Cualquier capacidad específica de tu producto —cualquier acción que un cliente externo no podría usar tal cual— va en servidor propio desde el primer día. No hay punto medio que aguante seis meses.

Políticas explícitas y autenticación fuera del modelo

La parte más difícil de hacer bien y la más importante: las credenciales no entran nunca en el contexto del modelo. La arquitectura de MCP está diseñada para que el modelo pida operaciones por nombre y parámetros y el servidor las ejecute con sus propias credenciales locales. Si esto se rompe —si en algún momento un token de API aparece en el prompt del agente o en un mensaje del modelo— ya has perdido la batalla de prompt injection.

El patrón canónico, documentado en la referencia del SDK de Anthropic^[3], es pasar credenciales como variables de entorno al arrancar el servidor (transporte stdio) o como cabeceras HTTP en el descriptor del servidor (transporte HTTP/SSE). En código, con el Claude Agent SDK, el registro de servidores MCP es API de primera clase mediante la opción mcpServers de query(), y el control de qué herramientas puede llamar el modelo se hace con allowedTools, no con instrucciones en el prompt. El SDK de Python expone exactamente la misma forma. Esto matters: las decisiones de seguridad se gestionan en código, fuera del lenguaje natural, donde son auditables.

Por encima de la autenticación está la política, y aquí hay tres niveles que conviene separar. La política se especifica en la capa del agente, no en el modelo. Cada servidor MCP declara qué herramientas expone; el agente decide:

1. qué herramientas se pueden invocar y con qué parámetros (allowedTools: ["mcp__filesystem__read_file"] es muy distinto de ["mcp__filesystem__*"])
2. qué operaciones requieren confirmación humana antes de ejecutarse: cualquier escritura en datos importantes, cualquier ejecución de comandos, cualquier llamada que mueva dinero
3. qué operaciones nunca se ejecutan de forma autónoma y deben ir por una vía manual o supervisada (borrados, despliegues a producción, operaciones en sistemas regulados)

Para servidores remotos, MCP soporta OAuth 2.1 desde la revisión de la especificación de marzo de 2025, y los SDKs aceptan tokens de acceso obtenidos por el flujo OAuth de tu aplicación pasados como cabecera Authorization: Bearer ${TOKEN} en el descriptor. La rotación funciona sin redesplegar el agente: cambias el token en el secreto y el siguiente arranque del servidor usa el nuevo.

Composición multi-servidor con prefijos de herramienta

Un agente que solo habla con un servidor MCP es la excepción. Lo habitual en 2026 es media docena: ficheros, base de datos, repositorio Git, CRM de dominio, búsqueda web, calendario. Para que el modelo pueda elegir entre todas sin que dos herramientas con el mismo nombre se pisen, el orquestador presenta cada herramienta con un prefijo del servidor. El SDK de Anthropic estandariza el formato mcp__<server-name>__<tool-name>:

import { query } from "@anthropic-ai/claude-agent-sdk";

const options = {
  mcpServers: {
    fs:  { command: "npx", args: ["-y", "@modelcontextprotocol/server-filesystem", "/srv/data"] },
    db:  { command: "npx", args: ["-y", "@modelcontextprotocol/server-postgres", process.env.DATABASE_URL] },
    web: { type: "http", url: "https://search.example.com/mcp", headers: { Authorization: `Bearer ${process.env.SEARCH_TOKEN}` } }
  },
  allowedTools: [
    "mcp__fs__read_file",
    "mcp__fs__list_directory",
    "mcp__db__query",
    "mcp__web__fetch"
  ]
};

El modelo ve cuatro herramientas con nombres únicos. Si pide mcp__db__query, el orquestador resuelve a “servidor db, método query” y enruta la llamada al subproceso correcto, con sus credenciales y su política. El modelo nunca elige a qué servidor va una operación; elige una herramienta concreta y el orquestador hace el resto.

Cuando el catálogo de herramientas crece, hay dos cuellos de botella prácticos. El primero es contexto: cada definición de herramienta ocupa tokens, y con cincuenta herramientas registradas el prompt de sistema se vuelve incómodo. El SDK de Anthropic incluye tool search, que retiene definiciones fuera de contexto y carga solo las relevantes para cada turno, activado por defecto desde 2025. El segundo cuello de botella es de diseño: si hay tres servidores que exponen search, conviene renombrarlos en la capa de política (docs:search, crm:search, web:search) para que el modelo pueda razonar sobre cuál usar sin hacer pruebas a ciegas.

Antipatrones reales de 2025–2026

Tras año y medio de despliegues, los errores recurrentes son cuatro y todos comparten una raíz: dar al modelo más capacidad de la que justifica la política.

Herramientas peligrosas sin política explícita

Exponer delete_file, rm -rf vía bash, db.execute con SQL libre o git push --force sin confirmación humana es el error más caro. El modelo no es malicioso, simplemente predice tokens; si entre los tokens que predice hay una llamada destructiva con argumentos plausibles, la lanzará. La mitigación es aburrida pero efectiva: lista blanca de herramientas, confirmación humana para cualquier escritura significativa, y para operaciones realmente irreversibles (borrados en producción, transferencias) un canal que no pase por el agente.

Servidores propios sin tests de contrato

Tu servidor MCP es una API más; si cambias el shape de una respuesta o renombras un argumento sin actualizar la versión, el agente se rompe en silencio en el siguiente arranque. La práctica madura en 2026 es CI con un cliente MCP de prueba que enumera herramientas, llama cada una con argumentos canónicos y verifica el shape de la respuesta. Snapshot tests del listado de herramientas detectan renames y removals al instante.

Memoria compartida entre servidores que deberían estar aislados

Si dos servidores MCP escriben y leen del mismo bucket o de la misma tabla auxiliar, has creado un canal lateral por el que un servidor puede envenenar el contexto que otro lee. Visto en producción más de una vez: un MCP de scraping web guardando contenido sin sanitizar en una tabla que un MCP de búsqueda interna después indexa, abriendo prompt injection desde la web abierta. Cada servidor con su propio almacenamiento.

Loops de reintentos sin breaker

El cliente reintenta una llamada MCP que falla, el servidor reintenta su backend, el agente reintenta el turno completo cuando ve un error genérico. Tres niveles de reintentos compuestos saturan rate-limits y producen costes inesperados. Backoff exponencial en cada nivel, breaker que abre tras N fallos consecutivos, y telemetría OTel del ratio de errores son la mitigación estándar.

Cómo elegir tu primer servidor MCP propio

Si vas a escribir tu primer servidor MCP de dominio, tres preguntas filtran bien la decisión.

¿Existe un servidor comunitario que cubra el caso de forma razonable? Si la respuesta es sí —y muchas veces lo es para casos genéricos como acceso a Postgres, GitHub o sistema de ficheros— empezar por ahí. Te ahorras la curva de aprendizaje del SDK y el mantenimiento. Si la respuesta es no, o el comunitario no se ajusta sin parches, sigues.

¿La lógica es de dominio o genérica? Si la herramienta hace algo específico de tu producto —crear una oportunidad en tu CRM, lanzar un build en tu pipeline, generar una factura con tu numeración— es lógica de dominio, y va en servidor propio desde el primer día. Si es genérico —leer ficheros, consultar una BD, hacer fetch HTTP— suele haber comunitario. La señal clara es: ¿podría un cliente externo usar esta herramienta exactamente igual que tú? Si sí, genérico. Si no, propio.

¿Necesita credenciales sensibles que controlas tú? Si la respuesta es sí —tokens de tu nube, claves de tus bases, certificados de mTLS— el servidor propio te da el control de la rotación, del binario y de la política de versionado. Un servidor comunitario que toca esas credenciales es un riesgo de cadena de suministro innecesario.

Una vez decidido que va en propio, el patrón pragmático para empezar es dos o tres herramientas, transporte stdio, política con confirmación humana para cualquier escritura. Iteras desde ahí. Tests de contrato desde el primer commit. Telemetría OTel con los atributos GenAI MCP desde el principio. Documentar el catálogo de herramientas como una API pública aunque solo la consuma tu agente.

Profundiza

• Claude Code vs Cursor vs Copilot en 2026: comparativa con tareas medidas
• Cómo construir un agente productivo con el SDK de Anthropic, paso a paso
• Sistemas multi-agente: LangGraph vs CrewAI vs Autogen en 2026
• Observabilidad de agentes con OpenTelemetry GenAI semconv en 2026

Conclusión

MCP es la elección por defecto en 2026 para conectar modelos a herramientas, y los equipos que sigan los patrones —servidores comunitarios para lo genérico, propios para el dominio, credenciales fuera del modelo, política explícita y composición con prefijos— tendrán agentes estables y portables entre proveedores. El estándar ha madurado, los SDKs son sólidos, la observabilidad está en la spec de OpenTelemetry y los antipatrones están bien documentados. No hay excusa razonable para empezar una arquitectura nueva con un mecanismo propietario.

Para temas adyacentes: el control directo del navegador como alternativa o complemento a MCP en Computer Use de Claude, y el puente con voz en tiempo real en la comparativa de agentes de voz multi-vendor.

Síguenos en jacar.es para más sobre MCP, agentes en producción, observabilidad GenAI y arquitectura de herramientas.

1. MCP
2. especificación GenAI de OpenTelemetry
3. referencia del SDK de Anthropic