Guía de introducción a MCP para desarrolladores frontend

Muchos ingenieros frontend se sienten confundidos la primera vez que se encuentran con MCP: el nombre suena a protocolo, el contenido parece un agente, y en las discusiones siempre aparecen Tool, Prompt, Resource, Skill. En realidad, no es necesario aprenderse todos los términos de golpe; basta con captar una idea: MCP es una forma estandarizada de permitir que la IA pueda conectar herramientas, obtener datos y realmente hacer cosas.

Si comparamos el modelo grande anterior con un colega que solo sabe hablar, después de integrar MCP, puede obtener la capacidad de consultar sistemas, llamar interfaces y leer archivos. Ya no solo responde preguntas, sino que también puede ayudarte a realizar algunas operaciones dentro del alcance autorizado. Esta es una de las razones importantes por las que MCP está siendo adoptado por cada vez más herramientas de desarrollo de IA.

¿Qué es MCP?

MCP son las siglas de Model Context Protocol, un protocolo abierto que se utiliza para conectar aplicaciones LLM con fuentes de datos externas, herramientas y capacidades del sistema.

Si lo entendemos de una manera familiar para el frontend, HTTP resuelve cómo se comunican el navegador y el servidor, mientras que MCP resuelve cómo se comunican las aplicaciones de IA con herramientas, recursos y contexto.

La documentación oficial de la arquitectura divide los roles de comunicación en Host, Client y Server: el Host es la aplicación LLM que inicia la conexión, el Client es el conector dentro del Host, y el Server es el proveedor de herramientas y capacidades de contexto.

Este diseño es muy similar a la estructura familiar para el frontend de 'aplicación anfitriona + SDK + servidor'. Puedes entenderlo como: el Host se encarga de la interfaz y el modelo, el Client de la comunicación según el protocolo, y el Server de proporcionar realmente las capacidades.

Veamos primero un ejemplo muy intuitivo

Supongamos que has creado un sistema de administración con un asistente de IA en la esquina inferior derecha. El usuario pregunta: '¿Cuántos pedidos nuevos se han creado hoy?'

Sin MCP, este asistente generalmente solo puede quedarse en la capa de chat: o adivina un resultado basado en los datos de entrenamiento, o tienes que escribir un conjunto adicional de formatos de llamada de herramientas para conectar directamente la interfaz de consulta de base de datos y la lógica de permisos.

Con MCP, el proceso es mucho más claro. El asistente de IA primero pregunta a un MCP Server: '¿Qué herramientas tienes?' El servidor devuelve una lista de herramientas, como get_today_orders, get_order_detail, export_report, cada una con una descripción de su propósito y un esquema de parámetros.

Luego, el modelo, al ver la pregunta del usuario, decide llamar a get_today_orders. El servidor consulta la base de datos, devuelve el resultado a la IA, y la IA responde en lenguaje natural: 'Se han creado 128 pedidos nuevos hoy'. Esta es la forma de uso más típica de MCP: primero descubrir herramientas, luego llamarlas, y finalmente organizar el resultado en frases que el usuario pueda entender.

¿Quiénes son realmente Host, Client y Server?

Estos tres términos aparecen a menudo juntos, pero no son nada difíciles. Podemos compararlos con una 'plataforma de delivery': el Host es como la app de delivery, el Client es como el sistema de gestión dentro de la app, y el Server es como el restaurante que realmente prepara la comida.

En MCP:

• El Host es la aplicación de IA que ves directamente, como Claude Desktop, Claude Code, algún plugin de IDE, o tu propia página web de IA.

• El Client es la capa dentro del Host que se encarga de comunicarse con el exterior según el protocolo MCP.

• El Server es la parte que realmente proporciona las capacidades, como un servicio de logs, un adaptador de sistema de archivos, un servicio de consulta de base de datos, o un servicio de herramientas de GitHub.

Pongamos un ejemplo de desarrollo. Supongamos que estás usando un asistente de programación de IA en VS Code y le pides: 'Ayúdame a ver qué interfaz de mi proyecto actual tiene más timeouts'. En ese momento, el asistente de IA en VS Code es el Host, la capa dentro del asistente que se encarga de la comunicación por protocolo es el Client, y los proveedores de capacidades que pueden acceder a logs, repositorios de código, plataformas de monitoreo, etc., son los MCP Servers.

Tool es lo primero que debes entender

Lo más importante en MCP no es Prompt ni Resource, sino Tool. Porque la mayoría de las experiencias en las que 'la IA realmente empieza a hacer cosas' comienzan con Tool.

Puedes entender Tool como una 'interfaz para la IA'. Generalmente contiene tres cosas: el nombre de la herramienta, una descripción de su propósito, y un esquema de parámetros, es decir, la definición de la estructura de los parámetros.

Por ejemplo, una herramienta del clima podría verse así:

• name: get_weather

• description: Consulta el clima actual de una ciudad

• input schema: location, tipo string, y obligatorio.

Cuando el cliente la llama, envía el nombre de la herramienta y los parámetros mediante una solicitud como tools/call. Las especificaciones y ejemplos oficiales siguen este patrón.

Otro ejemplo más cercano al frontend. Has creado un panel de contenido y puedes conectar tres herramientas al asistente de IA:

• search_articles: Busca artículos por palabra clave.

• get_article_detail: Obtiene los detalles de un artículo.

• publish_article: Publica un artículo.

Así, cuando el usuario dice 'Encuentra los borradores que tengan MCP en el título y publica el más reciente', la IA puede primero consultar la lista, luego obtener los detalles, y luego llamar a la interfaz de publicación. Te darás cuenta de que esto es básicamente exponer un conjunto de APIs del backend para que el modelo las combine y las llame.

¿Por qué es importante el schema?

Muchas personas, al ver MCP por primera vez, piensan que 'nombre de herramienta + descripción' es suficiente, pero preguntan por qué es necesario escribir un schema. La razón es simple: el modelo no llama herramientas adivinando; necesita un contrato de parámetros claro.

Por ejemplo, si escribes una herramienta create_user sin schema, el modelo podría no saber si email es obligatorio, ni si age debe ser un número o una cadena. Con el schema, tanto el modelo como el cliente pueden saber exactamente cómo construir los parámetros; el frontend también puede generar directamente formularios de depuración o definiciones de tipos basados en estas estructuras, una experiencia muy similar a la de depurar interfaces con documentos Swagger.

Por eso MCP es amigable para los ingenieros frontend. No es una forma de integración que dependa completamente de la adivinanza mediante prompts, sino que estructura, clarifica y hace verificables las capacidades de las herramientas en la medida de lo posible.

¿Cómo ocurre realmente una llamada completa?

Usemos un escenario simple para explicarlo: el usuario escribe en el asistente de IA 'Ayúdame a ver cuántos usuarios nuevos se han registrado hoy'.

Primer paso: el Host sabe qué MCP Servers tiene conectados, por ejemplo, un analytics server. Este servidor expone la herramienta get_signup_count.

Segundo paso: el Client obtiene la definición de la herramienta mediante tools/list, y sabe que esta herramienta necesita un parámetro date de tipo string.

Tercer paso: el modelo determina que esta pregunta requiere llamar a get_signup_count, por lo que el cliente envía una solicitud tools/call con los parámetros, posiblemente { "date": "2026-05-03" }.

Cuarto paso: el Server consulta la base de datos o el servicio de análisis y devuelve el resultado, por ejemplo, 356. Luego el Host organiza este resultado en un mensaje orientado al usuario: 'Hoy se han registrado 356 nuevos usuarios.'

El punto clave de este proceso es que el modelo no opera directamente la base de datos; siempre realiza la acción indirectamente a través de una herramienta claramente definida. Esto facilita la gestión de permisos, seguridad, auditoría y manejo de errores.

Resource y Prompt: solo necesitas saber para qué sirven por ahora

Además de Tool, en MCP también se mencionan a menudo Resource y Prompt. Son útiles, pero en la fase de introducción no hace falta profundizar demasiado.

Resource se parece más a 'material para que el modelo lo vea', no necesariamente una acción ejecutable. Por ejemplo, los logs de errores de la última hora, el contenido del archivo abierto actualmente, el README de un proyecto, o la descripción de la estructura de una tabla de base de datos, todo esto se puede proporcionar como Resource para que el modelo lo consulte.

Por ejemplo, cuando el usuario pregunta '¿Por qué esta interfaz siempre da timeout?', la IA puede no necesitar llamar muchas herramientas de inmediato, sino primero leer un Resource de logs y un Resource de código, y luego analizar el problema. Los ejemplos oficiales sobre prompts y resources muestran este uso de proporcionar logs y archivos de código juntos al modelo.

Prompt, por otro lado, se parece más a una plantilla de tarea reutilizable. Por ejemplo, proporcionar un prompt git-commit que, al recibir los cambios de código, genere un mensaje de commit con un estilo uniforme; o un prompt explain-code dedicado a explicar un fragmento de código.

Si solo quieres recordar la diferencia más simple, puedes entenderlo así: Tool es un 'botón que puede hacer cosas', Resource es 'material para que el modelo vea', y Prompt es una 'plantilla de trabajo habitual'.

¿Por qué el frontend se beneficia claramente?

El mayor beneficio para el frontend no es que 'también pueda escribir protocolos', sino que la forma de interacción cambiará.

Antes, el asistente de IA en una página generalmente solo tenía un cuadro de entrada y podía hacer muy pocas cosas. Ahora, si detrás está conectado MCP, el frontend puede mostrar muchas cosas explícitamente, como qué herramientas tiene la IA, qué herramienta va a llamar esta vez, por qué solicita cierto permiso, cuál es el resultado de la llamada, y en qué paso falló.

Esto hará que el producto de IA sea más como un 'panel de trabajo observable y controlable', en lugar de una caja negra de chat. Especialmente en escenarios como sistemas de administración, IDEs y herramientas internas, los usuarios suelen preferir ver lo que realmente hizo la IA, en lugar de recibir solo una respuesta misteriosa.

Otro ejemplo cercano al flujo de trabajo frontend. Creas una página de análisis de logs, y cuando el usuario selecciona un log de error, el asistente de IA en el lado derecho obtiene automáticamente estos contextos: nombre del servicio actual, rango de tiempo del error, fragmento de log seleccionado, nombre de la rama actual del repositorio.

Luego el usuario solo dice: 'Ayúdame a analizar la causa'. En ese momento, la IA puede primero leer el Resource de logs, luego llamar a herramientas como search_recent_deploys, get_error_rate, y finalmente devolver un análisis más confiable. La clave de esta experiencia no es que el modelo sea más inteligente, sino que el frontend ha convertido el estado de la interfaz en contexto utilizable por el modelo.

¿En qué posición se encuentra MCP ahora?

Desde 2025-2026, lo más discutido en el sector son varios Skill, Workflow y orquestación de agentes; la popularidad de MCP parece no ser tan alta como cuando recién apareció. Pero desde una perspectiva de ingeniería, por más popular que sea Skill, detrás de él, muchas veces sigue siendo MCP el que hace el trabajo.

Un ejemplo concreto lo deja claro:

• Skill es como un conjunto de 'guiones y procesos para que el servicio al cliente maneje reembolsos': primero confirmar el pedido, luego consultar el estado del pago, luego verificar el control de riesgos, y finalmente dar el resultado del proceso.

• MCP es como la 'capa de interfaz unificada detrás del sistema de atención al cliente', que te ayuda a conectar el servicio de pedidos, el servicio de pagos, el servicio de control de riesgos, de modo que cada paso de 'ir a consultar' tenga una herramienta correspondiente que se pueda llamar.

En el escenario de desarrollo, es lo mismo:

• Skill puede definir 'cómo hacer una revisión de código': primero ver el diff, luego los tests, luego los logs de errores, y finalmente generar la opinión de revisión.

• Las acciones reales de obtener el diff, consultar CI, leer logs, generalmente se realizan a través de herramientas expuestas por MCP; Skill se encarga de 'en qué orden usar qué herramientas', mientras que MCP se encarga de 'cómo conectar, llamar y obtener resultados de esas herramientas'.

Por lo tanto, el panorama actual es más bien: la comunicación externa y los puntos de venta del producto se centran más en lo inteligente que es Skill y lo automatizado del proceso; pero en el fondo, en el código, MCP sigue siendo esa 'regleta' estable que conecta el modelo con varios sistemas de negocio, pasarelas de seguridad, bases de datos y plataformas de logs.

Quizás su nombre no sea tan popular como Skill, pero mientras estés construyendo un producto que 'permita a la IA operar sistemas y consultar datos reales', alguien tiene que hacerse cargo de la capa de protocolo, y MCP está desempeñando ese papel silencioso pero crucial en muchos proyectos.

Diferencia entre MCP y Skill

Para distinguirlos con una sola frase: MCP resuelve 'cómo conectar herramientas', Skill resuelve 'cómo hacer la tarea'.

Usemos el ejemplo del 'asistente de revisión de código'.

Si ahora te preocupa: cómo hacer que la IA acceda a Git diff, cómo consultar resultados de CI, cómo leer informes de lint, entonces te enfrentas a un problema de MCP, porque todo esto pertenece a 'conectar capacidades'.

Pero si te preocupa: qué se revisa primero en la revisión de código, qué riesgos deben señalarse prioritariamente, en qué formato se debe escribir el resultado, en qué casos se debe sugerir agregar pruebas, entonces esto se parece más a un problema de Skill, porque se está definiendo 'cómo se debe hacer esta tarea'.

En la realidad, ambos suelen aparecer juntos. MCP se encarga de conectar Git, CI, plataforma de logs; Skill se encarga de solidificar el 'proceso de revisión de código'. Pero para una comprensión inicial, basta con tener clara esta frontera.

¿Por qué vale la pena aprenderlo?

Vale la pena aprender MCP, no porque sea un término nuevo, sino porque estandariza la capa que más tiende a ser caótica en el desarrollo de productos de IA: descubrimiento de herramientas, descripción de parámetros, transmisión de contexto y ejecución de llamadas.

Cuando esta capa está estandarizada, los ingenieros frontend no tienen que reinventar un protocolo de 'cómo conectar el modelo con las capacidades del backend' cada vez que hacen un nuevo producto de IA.

Más importante aún, esta estandarización hace que los límites de las responsabilidades del frontend sean más interesantes. La página ya no es solo un contenedor de entrada y salida, sino que se convierte gradualmente en una consola de control del comportamiento de la IA: mostrar herramientas, explicar estados, presentar planes, solicitar autorizaciones, devolver resultados.

Esto permite que los ingenieros frontend no solo 'integren un SDK' en los productos de IA, sino que realmente participen en la definición de la forma de interacción entre humanos y máquinas.

Conclusión

Para resumirlo en una sola frase, el valor de MCP es: proporciona a las aplicaciones de IA, por primera vez, una capa de 'integración de capacidades externas' relativamente unificada, reutilizable e ingenieril.

Para los ingenieros frontend, entenderlo no requiere convertirse primero en expertos en IA; basta con verlo como una nueva capa de protocolo, una forma de conexión estándar que permite que la interfaz, el modelo y los sistemas de negocio trabajen juntos.