Curso
Creación de sistemas agentic escalables
1 h 30 min
16K
Hace año y medio, el Model Context Protocol aún era un término de nicho fuera de Anthropic. Hoy aparece en entrevistas para ingeniería de IA, developer relations y roles de backend porque muchos equipos que lanzan agentes tienen un servidor o cliente MCP en algún punto de su stack.
MCP (Model Context Protocol) es un protocolo abierto que estandariza cómo las aplicaciones de IA se conectan a herramientas externas, datos y plantillas de prompts. Resuelve el problema de integración N x M: sin un protocolo compartido, cada pareja modelo-herramienta necesita su propio conector. Con MCP, construyes el conector una vez y cualquier host compatible puede usarlo. Puede que lo oigas como "el USB-C de la IA", útil como explicación inicial y poco más.
Lo que te pregunten depende mucho del rol. A una persona junior pueden pedirle que explique herramientas frente a recursos. A una ingeniera de plataforma es más probable que le pregunten cómo un núcleo sin estado cambia el despliegue. He organizado la guía por dificultad y casos de uso, así que céntrate en las secciones que encajan con tu rol.
El tiempo importa, y lo remarco porque MCP sigue cambiando. A fecha de hoy, la especificación estable actual es 2025-11-25. Hay una release candidate para 2026-07-28 ya bloqueada y prevista para dentro de unas cuatro semanas, así que todo lo que venga de esa RC está marcado como a futuro.
Preguntas de entrevista MCP para principiantes
Salen en muchos filtros, sea cual sea la seniority. Yo empezaría por el vocabulario.
¿Qué es MCP y por qué se creó?
MCP es un estándar abierto, creado originalmente por Anthropic y liberado como open source en noviembre de 2024, para conectar aplicaciones de IA con herramientas y fuentes de datos externas. Dicho de forma directa: implementa MCP una vez y podrás hablar con cualquier servidor compatible con MCP en lugar de escribir un conector nuevo para cada herramienta.
¿Qué es un servidor MCP?
Un servidor es un programa que expone herramientas, recursos y prompts a un cliente MCP. Puede ejecutarse como subproceso local vía stdio o como proceso remoto independiente accesible por HTTP. El servidor no sabe nada del modelo; responde a las peticiones según el protocolo.
¿Qué es un cliente MCP?
El cliente es el conector a nivel de protocolo que vive dentro de una aplicación host (piensa en Claude Desktop, VS Code o Cursor) y habla con un servidor cada vez mediante JSON-RPC. Un mismo host puede ejecutar varios clientes, cada uno con su conexión uno a uno a un servidor.
¿En qué se diferencia MCP de una API REST normal?
Una API REST está pensada para que la llamen desarrolladores desde código. MCP está pensado para que un LLM la descubra y la invoque en tiempo de ejecución. Esa distinción importa más que el formato en el cable. Un cliente puede pedir a un servidor tools/list y recibir una descripción estructurada de las capacidades disponibles, algo que una REST típica no ofrece por defecto. Para una integración simple, una llamada directa a la API suele ser más rápida y barata.
¿Qué tipos de recursos puede exponer un servidor?
Cualquier cosa direccionable por una URI: archivos, registros de base de datos, documentos, valores de configuración, respuestas de APIs. Los recursos son contexto de solo lectura, no acciones, que es una confusión habitual al empezar.
Preguntas sobre conceptos centrales de MCP
Cuando el vocabulario está claro, las entrevistas pasan a cómo se comunican las piezas.
¿Cuál es la arquitectura a alto nivel?
Tres roles: host, cliente y servidor. El host es la aplicación que usa la persona. Instancia uno o más clientes, y cada cliente mantiene una sola conexión a un servidor. Cada mensaje entre cliente y servidor es JSON-RPC 2.0, lo que te da un formato estable independientemente del transporte.
¿Cuáles son las tres fases del ciclo de vida de una conexión?
Inicialización, operación y cierre. Durante la inicialización, el cliente envía su versión de protocolo y capacidades soportadas, y el servidor responde con las suyas. Una vez que ambas partes acuerdan, las peticiones normales como tools/list y tools/call ocurren en la fase de operación. El cierre es simplemente un fin ordenado.
¿Qué transportes usa MCP hoy?
stdio para servidores locales basados en subprocesos, y Streamable HTTP para servidores remotos. Streamable HTTP sustituyó al transporte HTTP más SSE en la especificación 2025-03-26, así que describir dos endpoints SSE por separado ya está desactualizado.
¿Cuál es la diferencia real entre herramientas, recursos y prompts?
La distinción va de control, no de tipo de dato:
- Las herramientas las controla el modelo. El LLM decide cuándo llamarlas según el contexto.
- Los recursos los controla la aplicación. El host o la persona usuaria decide cuándo cargarlos.
- Los prompts los controla la persona. Se elige explícitamente una plantilla antes de empezar la inferencia.
Muchas personas los definen por el tipo de dato que llevan, y eso pierde el punto clave.
Preguntas sobre herramientas, recursos y prompts en MCP
Una vez entendido el modelo de control, la siguiente cuestión es cómo son estos elementos en la práctica.
¿Qué incluye la definición de una herramienta?
Un name, una description, un inputSchema escrito en JSON Schema y, desde la especificación 2025-06-18, un outputSchema opcional más annotations que describen comportamientos como si una herramienta es de solo lectura o destructiva. Los clientes deberían tratar las anotaciones como no confiables a menos que provengan de un servidor de confianza. Son pistas, no garantías.
¿Cuándo algo debe ser una herramienta y no un recurso?
Si tiene efectos secundarios o necesita un cálculo vivo y reciente, es una herramienta. Si es información estática o semiestática sin efectos secundarios, es un recurso. Consultar el tiempo contra una API en vivo es una herramienta. Una lista en caché de ciudades soportadas es un recurso.
¿Qué hace buena a una herramienta MCP, además de que funcione?
Diseñala en torno a lo que la persona quiere conseguir, no a los endpoints que tengas a mano. Una herramienta debe envolver un flujo de trabajo completo, no una sola llamada cruda a una API. Su descripción también importa: ese texto entra en el contexto del modelo e influye en si elige bien la herramienta. Aquí tienes un ejemplo mínimo con la capa FastMCP del SDK de Python:
from mcp.server.fastmcp import FastMCP
app = FastMCP("weather-demo")
@app.tool()
async def get_weather(city: str) -> str:
"""Get the current weather for a city."""
return f"Weather data for {city}"
@app.resource("config://units")
async def get_units() -> str:
"""Static configuration for the unit system in use."""
return '{"temperature": "celsius"}'La docstring de la herramienta se convierte en su descripción; el recurso es dato estático detrás de una URI, sin efectos secundarios.
¿Cómo recupera un cliente un recurso?
Llama a resources/read sobre una URI obtenida de resources/list. Si el servidor soporta la capacidad listChanged, puede notificar al cliente cuando la lista de recursos cambie. Sin esa capacidad, el cliente no tiene señal y tiene que sondear o refrescar manualmente.
Preguntas sobre desarrollo de servidores MCP
Aquí el conocimiento conceptual tiene que convertirse en algo que funcione.
¿Qué SDK oficiales existen y están todos igual de maduros?
No. Los SDK están en niveles: TypeScript, Python, C# y Go están en el Nivel 1 con soporte completo de funcionalidades, Java y Rust son Nivel 2, y Swift, Ruby, PHP y Kotlin son Nivel 3. El SDK de Python incluye FastMCP, su API de servidor basada en decoradores.
¿Cuál es el bug más común que rompe un servidor local?
Escribir en stdout cuando no debes. Un transporte stdio usa stdout exclusivamente para mensajes JSON-RPC, así que un print() o console.log() fuera de lugar corrompe el flujo de mensajes y el parser del cliente se atraganta. Todo lo que quieras registrar para depuración debe ir a stderr.
MCP Inspector mostrando herramienta y recurso. Vídeo del autor.
¿Cómo funciona el manejo de errores en MCP y por qué importa en entrevistas?
Hay tres niveles. Los fallos de transporte son problemas de conexión. Los errores de protocolo usan códigos estándar de JSON-RPC (-32700 para error de parseo, -32600 hasta -32603 para peticiones inválidas, métodos desconocidos y similares). Los fallos a nivel de aplicación, como que una API dentro de tu herramienta devuelva un error, deben devolverse con isError: true en el resultado de la herramienta para que el modelo pueda verlo y reaccionar.
return {
"content": [{"type": "text", "text": "Rate limit exceeded, try again later"}],
"isError": True
}Esa marca permite que el modelo vea el fallo e intente algo distinto.
¿MCP es con estado ahora mismo?
Sí, hoy las sesiones se rastrean a nivel de conexión. Esto crea problemas de escalado en producción, que cubriré en la sección de diseño de sistemas.
Preguntas sobre seguridad y gobernanza en MCP
La seguridad aparece ya en muchas entrevistas sobre MCP, especialmente para roles de plataforma y empresa.
¿Cómo difiere la autenticación entre los transportes stdio y HTTP?
Para servidores locales con stdio, la autenticación en la práctica es opcional; ya confías en el proceso que has lanzado. Para servidores remotos basados en HTTP, OAuth 2.1 es el marco, y los servidores se clasifican como resource servers de OAuth 2.0 según la especificación 2025-06-18. OAuth no es obligatorio en todo MCP.
¿Qué es el tool poisoning?
Son instrucciones maliciosas ocultas en los metadatos de una herramienta, normalmente en la descripción o el esquema, que el modelo lee al decidir qué herramienta llamar. No hace falta que la herramienta se invoque para que importe, porque el modelo ya vio esas instrucciones al listar la herramienta.
¿En qué se diferencia un ataque rug pull del tool poisoning?
El tool poisoning es un problema de entrada. Un rug pull es un problema de persistencia: una herramienta parece limpia cuando la apruebas, luego su definición cambia, y la mayoría de clientes no tienen forma incorporada de forzar una nueva aprobación. Defenderte de uno no te protege del otro.
¿Qué es Enterprise-Managed Authorization y por qué importa ahora?
EMA es una extensión de MCP que pasó a estable el 18 de junio de 2026. Traslada la decisión de autorización al proveedor de identidad de la organización en lugar del consentimiento servidor a servidor de cada empleado. El cliente obtiene un Identity Assertion JWT firmado durante el single sign-on y lo intercambia por un token de acceso con alcance del servidor de autorización. Anthropic, Microsoft y Okta lo soportan.
Preguntas sobre MCP y agentes de IA
Aquí es donde el protocolo se cruza con el diseño de agentes.
¿Por qué MCP importa específicamente para los agentes?
Los agentes necesitan contexto y acción. MCP pone ambos en un único protocolo. Como se dijo antes, tools/list permite que un agente descubra qué hay disponible en vez de depender de una lista fija en su código.
Modelo de host, cliente y servidor del agente. Imagen del autor.
¿Cuál es la diferencia entre MCP y A2A?
La regla corta: MCP conecta agentes con herramientas; A2A conecta agentes entre sí. Ambos protocolos están ahora bajo la Agentic AI Foundation, así que se tratan como capas separadas, no como competidores.
¿Qué es la primitiva de sampling y debería seguir mencionándola?
Sampling permite que un servidor solicite una completion al modelo a través del cliente, que es cómo un servidor puede ejecutar comportamiento tipo agente sin guardar claves de API. Conoce la primitiva, pero añade el matiz: la RC 2026-07-28 marca Sampling, Roots y Logging como deprecadas bajo la nueva política de ciclo de vida. Seguirán funcionando al menos doce meses, pero a los autores de servidores cada vez más se les recomienda llamar directamente a la API del proveedor del modelo.
¿Cómo evitan los agentes saturar su ventana de contexto con definiciones de herramientas?
No cargando todas las definiciones desde el principio. El enfoque de Tool Search de Anthropic retrasa la carga de esquemas de herramientas hasta que se necesitan, y su artículo técnico reporta una reducción del 85% en uso de tokens en setups con muchas herramientas manteniendo toda la librería accesible. En una respuesta de entrevista, combinaría carga diferida con servidores de alcance estrecho.
Preguntas de diseño de sistemas con MCP
Las preguntas de escenario prueban si puedes aplicar estas ideas con restricciones, no solo recitar definiciones.
Diseña un sistema de recuperación de documentos usando MCP.
MCP y RAG no compiten aquí. RAG gestiona la recuperación vectorial preindexada; MCP expone esa recuperación como herramienta o recurso que el agente puede invocar en vivo, junto con otras acciones que necesite. Trata la pregunta como cómo encajan ambas piezas, no cuál sustituye a la otra.
Diseña un servidor MCP para datos internos de la empresa.
Empieza por responsabilidad única: un servidor por dominio, como uno para base de datos y otro separado para archivos, en lugar de uno que haga de todo. Añade OAuth 2.1, ámbitos de mínimo privilegio por herramienta y auditoría desde el inicio, porque el control de acceso es más difícil de arreglar cuando el servidor ya está en producción.
¿Cómo escalarías un despliegue MCP hoy, antes de que llegue la especificación sin estado?
Mucha gente tropieza describiendo la especificación futura como si ya hubiera llegado. La condición con estado que vimos en la sección de servidores es el problema de escalado: el escalado horizontal necesita enrutamiento con afinidad, un almacén de sesión compartido o una pasarela MCP. La RC 2026-07-28 elimina las sesiones a nivel de protocolo, pero eso aún no está en vivo.
¿Cómo evitas que un despliegue grande con varios servidores ahogue al modelo en tokens?
La carga diferida del apartado de agentes ayuda aquí también. A nivel de despliegue, además filtra y agrega datos en el servidor antes de que lleguen al contexto del modelo, y pagina cualquier lista. La regla es controlar lo que entra en la ventana de contexto.
Preguntas de integración de MCP
Las preguntas de integración comprueban si entiendes dónde aparece MCP en herramientas comunes de desarrollo.
¿Cómo aparece MCP en los productos de Claude?
Claude.ai, Claude Desktop y Claude Code soportan MCP, y Anthropic mantiene un directorio de conectores con servidores preconstruidos. También hay un conector MCP en la Messages API para servidores remotos, aún en beta en el momento de escribir esto.
Claude Desktop mostrando un servidor MCP conectado. Imagen del autor.
¿MCP solo es útil con Claude?
No. OpenAI adoptó MCP en su Agents SDK y Apps SDK desde marzo de 2025. VS Code incorporó soporte para toda la especificación a mediados de 2025, Cursor soporta MCP mediante mcp.json, y Google Cloud tenía más de 50 servidores MCP gestionados en GA o en vista previa en abril de 2026.
¿En qué se diferencia MCP de RAG, en concreto?
Esta es la respuesta corta del diseño de sistemas: RAG responde desde una base de conocimiento programada; MCP gestiona consultas en vivo y acciones.
Preguntas de entrevista avanzadas sobre MCP
Las preguntas avanzadas comprueban si sigues la evolución del protocolo, no solo cómo funciona hoy.
¿Puedes recorrer el historial de versiones de la especificación?
Se pregunta para ver si sabes qué cambió y cuándo. Importan cinco revisiones, y solo una sigue siendo especulativa:
|
Versión |
Fecha |
Qué cambió |
|
2024-11-05 |
Nov 2024 |
Lanzamiento inicial |
|
2025-03-26 |
Mar 2025 |
Streamable HTTP sustituye a HTTP+SSE; se introduce OAuth 2.1 |
|
2025-06-18 |
Jun 2025 |
Salidas estructuradas de herramientas, elicitation, clasificación como OAuth resource server |
|
2025-11-25 |
Nov 2025 |
Spec estable actual; Tasks asíncronas (experimental), gobernanza formalizada |
|
2026-07-28 |
RC bloqueada mayo 2026 |
Núcleo sin estado, MCP Apps, marco de extensiones |
La clave es saber qué fila se ha publicado de verdad.
¿Quién gobierna MCP ahora?
Anthropic donó el protocolo a la Agentic AI Foundation, un fondo dirigido bajo la Linux Foundation, el 9 de diciembre de 2025. Block y OpenAI cofundaron la AAIF junto a Anthropic, con Google, Microsoft, AWS, Cloudflare y Bloomberg como miembros de apoyo. Los maintainers conservaron el control de las decisiones técnicas; la gobernanza pasó a una fundación más amplia.
¿Qué está cambiando realmente en el lanzamiento 2026-07-28?
El cambio principal es el núcleo sin estado del apartado de diseño de sistemas: el handshake initialize/initialized y la cabecera Mcp-Session-Id desaparecen, sustituidos por información de capacidades que viaja en _meta en cada petición. Eso elimina la necesidad de enrutamiento con afinidad. Un marco de extensiones también define cómo capacidades opcionales como MCP Apps y Tasks se publican y estabilizan por su cuenta.
¿Qué son las extensiones de MCP y funcionan en todas partes?
No. Las extensiones son capacidades opt-in, como Enterprise-Managed Authorization, OAuth Client Credentials para autenticación máquina a máquina y MCP Apps para UI interactiva dentro de un host. El soporte varía según el cliente, así que no diseñes asumiendo soporte universal.
Preguntas de entrevista basadas en escenarios
Evalúan el razonamiento diagnóstico más que datos memorizados, así que estructura las respuestas como camino de síntoma a causa y a solución.
Las llamadas a herramientas fallan de forma intermitente. ¿Qué miras primero?
Comprueba si los fallos vuelven como isError: true en el resultado de la herramienta o como error a nivel de protocolo. Eso te dice si el problema está dentro de la lógica de la herramienta o en el transporte. A partir de ahí, mira los límites de tasa de lo que envuelve la herramienta y comprueba timeouts antes de culpar al modelo.
Un agente sigue actuando con datos de recursos obsoletos. ¿Por qué?
Volvemos a la pregunta de recursos: listChanged es lo que avisa a un cliente de que un recurso cambió. Sin declararlo, el cliente no tiene señal y sirve una instantánea en caché hasta que algo obliga a refrescar.
Un servidor MCP se ha convertido en un claro cuello de botella. ¿Qué haces?
Divide por dominios, añade pools de conexiones y escala horizontalmente. Hasta que llegue el núcleo sin estado, puede que sigas necesitando la afinidad de sesión comentada en diseño de sistemas.
Datos sensibles se filtraron a través de una llamada a herramienta. ¿Cómo pasó?
Dos causas comunes son una herramienta con permisos más amplios de lo necesario, o falta de saneado de salida antes de que los datos llegaran al contexto del modelo. Mínimo privilegio por herramienta y un paso de saneado antes del contexto son las soluciones. El tool poisoning también está relacionado: se puede instruir al modelo para reenviar datos sin escribir código de exfiltración.
Errores comunes en entrevistas sobre MCP
Hay patrones que aparecen lo bastante a menudo como para destacarlos:
-
Tratar MCP como un reemplazo directo de REST tras la distinción explicada antes
-
Definir herramientas frente a recursos por tipo de dato cuando ya se explicó el modelo de control
-
Suponer la misma norma de autenticación para
stdioy HTTP -
Dar la respuesta heredada de SSE tras el cambio de transporte explicado
-
Mezclar la spec publicada con la RC 2026-07-28
-
Omitir los riesgos de seguridad al diseñar un sistema de llamadas a herramientas
La mayoría de estos errores vienen de tutoriales antiguos.
Cómo prepararte para entrevistas sobre MCP
La práctica práctica importa en este protocolo.
-
Construye un servidor pequeño con FastMCP o el SDK de TypeScript, expón una herramienta y un recurso, y ponlo a andar
-
Instala el Inspector oficial (
npx @modelcontextprotocol/inspector) y observa el tráfico JSON-RPC en bruto -
Conecta tu servidor a un cliente real, Claude Desktop, VS Code o Cursor, y mira el handshake de inicialización
-
Lee el changelog real de la especificación, no un resumen de terceros, especialmente las entradas de 2025-06-18 y 2025-11-25
-
Elige un escenario de diseño de sistemas de este artículo y escribe una respuesta completa antes de tu entrevista
Estos pasos separan el conocimiento de definiciones de la familiaridad práctica.
Conclusión
Ya no creo que memorizar definiciones de MCP sea suficiente. Lo difícil es saber qué respuesta corresponde a qué versión de la spec. Los despliegues actuales aún lidian con sesiones a nivel de conexión; la RC 2026-07-28 apunta a un núcleo sin estado. Si confundes ambas, tu respuesta de arquitectura sonará más segura que precisa.
Por eso trataría MCP como algo para probar, no solo leer. Construye el servidor pequeño del apartado de preparación, mira cómo un cliente lista herramientas y lee recursos, y fíjate en dónde acaba el protocolo y empieza tu diseño de aplicación. La respuesta útil en entrevista no es "MCP es el USB-C de la IA". Es "esto es lo que MCP estandariza, esto lo que no, y esto es lo que ha cambiado recientemente".
Para seguir de forma más estructurada, nuestro curso Building Scalable Agentic Systems cubre MCP y A2A en el contexto de diseño, pruebas y despliegue de agentes.