MCP y la diferencia entre tools, resources y prompts

Un modelo conectado a tu sistema bancario o a tu ERP no toca los datos por sí mismo: alguien decidió que esa acción concreta podía ejecutarse. Sherpa Platform expone información financiera y bancaria a través de un servidor MCP y quien controla cada decisión cambia según el caso.

ARTURO G. BRUNO
Software Engineer

Cada vez es más habitual conectar modelos de lenguaje a sistemas de producción y Model Context Protocol (MCP) es el estándar que lo hace posible sin integradores a medida. La diferencia entre tools, resources y prompts en MCP es lo que decide, en cada caso, quién controla esa conexión: el modelo, la aplicación o el usuario.

El modelo decide cuándo llamar a una tool; la aplicación decide qué resource carga en el contexto; el usuario decide cuándo invoca un prompt. Por eso el diseño de un servidor MCP empieza por una pregunta previa a cualquier línea de código: qué capacidades quieres exponer. De esa respuesta sale si cada capacidad nace como tool, resource o prompt, y no al revés.

El problema que resuelve MCP: integraciones a medida que dejan de escalar

Antes de MCP, conectar una aplicación de IA con un sistema externo significaba escribir un conector propio por cada combinación. Para tres aplicaciones y tres fuentes de datos, resultan nueve integraciones distintas que alguien tiene que mantener. Mantener esas nueve integraciones vivas cuesta más que escribirlas: cada vez que cambia el modelo, el sistema externo o quien las tocó por última vez, alguien tiene que revisarlas una a una.

MCP soluciona ese problema porque es un protocolo abierto, con una especificación pública y SDKs en varios lenguajes, sin dueño único, que estandariza cómo un cliente de IA habla con un servidor de capacidades usando mensajes JSON-RPC 2.0 para peticiones, respuestas y notificaciones. Si una aplicación de IA y una herramienta externa hablan ese mismo protocolo, conectarlas deja de ser un proyecto de integración a medida: basta con que ambas hablen MCP. Lo lanzó Anthropic a finales de 2024 y sigue evolucionando: se versiona por fecha, no por número de versión.

MCP se sostiene en tres pilares que conviene tener claros antes de entrar en la arquitectura:

• Abierto. Cualquier cliente compatible habla con cualquier servidor compatible, sin acuerdo previo entre quienes los construyeron.
• Cliente-servidor. El servidor expone capacidades; el cliente las consume y las controla.
• JSON-RPC 2.0. Todo el tráfico entre cliente y servidor pasa por este formato de mensajes.

Llevamos años viendo el mismo patrón en proyectos de desarrollo de software: cuanto más a medida es una integración, más caro sale sostenerla en caso de que haya que cambiar una sola pieza del sistema. MCP traslada ese mismo principio a la conexión entre modelos y sistemas externos, con una ventaja añadida: si mañana cambias de proveedor de LLM, tu servidor MCP sigue funcionando, porque nunca dependió de qué modelo había al otro lado.

Host, cliente y servidor: los roles del protocolo

Entender quién es quién en una conexión MCP evita un malentendido que he visto repetirse: dar por hecho que el modelo accede a los datos directamente. No ocurre así en ningún caso, porque entre el modelo y el sistema externo hay tres piezas con responsabilidades separadas —host, cliente y servidor— y es precisamente esa separación la que impide que el modelo toque nada por su cuenta. Vale la pena distinguirlas una por una.

Host

Es la aplicación de IA con la que interactúa el usuario: aloja al cliente (o a los clientes) MCP y gestiona la interacción con el modelo.

Cliente

Vive dentro del host y se dedica en exclusiva a conectarse con un servidor MCP concreto —la relación es siempre uno a uno—. Cuando el modelo quiere usar una capacidad, es el cliente quien formula la petición JSON-RPC y la envía al servidor.

Servidor

Expone esas capacidades sobre el sistema externo y responde a la petición del cliente.

Ciclo de vida de una conexión

Toda conexión pasa por dos fases.

• En la de inicialización ocurre un handshake: cliente y servidor se presentan y negocian qué capacidades soporta cada uno, porque no todos los clientes las soportan todas.
• Superada esa fase entra la de operación, el flujo normal de peticiones, respuestas y notificaciones durante el resto de la sesión.

Transporte: stdio y Streamable HTTP

La especificación define dos estándares de transporte:

• stdio para conexiones locales —una integración de desarrollo, una herramienta de escritorio—
• Streamable HTTP para conexiones remotas, la opción habitual cuando el servidor queda expuesto a usuarios externos.

El transporte antiguo de dos endpoints con HTTP + SSE quedó obsoleto en la especificación 2025-03-26. Una conexión remota necesita autenticación: normalmente OAuth, algo que desarrollamos en el segundo artículo de esta serie.

La diferencia entre tools, resources y prompts en MCP

El servidor puede ofrecer tres tipos de capacidades y a cada una la distingue quién decide cuándo se usa:

1. Tools. Funciones que el modelo puede invocar para consultar o actuar sobre el sistema externo. Las controla el modelo: decide cuándo llamarlas, con qué argumentos y cómo encadenarlas hasta tener suficiente información para responder.
2. Resources. Datos de solo lectura, identificados por URI, de tipo texto o binario. Los controla la aplicación: el host decide qué carga en el contexto del modelo y en qué momento. Tampoco todos los clientes los consumen igual: algunos dejan elegir al usuario, otros los inyectan directamente.
3. Prompts. Plantillas de interacción predefinidas y parametrizables, pensadas para invocarse como comandos de tipo slash. Los controla el usuario, que decide cuándo lanzarlas.

El flujo de una tool sigue siempre el mismo patrón: el usuario pregunta en lenguaje natural, el modelo propone llamar a una tool, el cliente ejecuta esa llamada contra el servidor y la respuesta viaja de vuelta hasta que el modelo tiene lo que necesita para contestar —o pide otra tool más—. Ese ir y venir puede repetirse varias veces en un mismo turno y es justo lo que se ve en la demo de la siguiente sección.

El protocolo, además, es bidireccional: el servidor puede pedirle cosas al cliente.

• Roots. El cliente delimita en qué rutas de archivos puede operar el servidor.
• Sampling. El servidor delega en el LLM del cliente para razonar sobre algo.
• Elicitation. El servidor pide información adicional al usuario a mitad de una operación.

En los tres casos, el cliente media siempre: ni el servidor habla directamente con el usuario, ni el modelo decide solo qué archivos leer. Es la misma lógica de control de todo el protocolo, en sentido contrario: cada acción pasa siempre por la pieza que el protocolo designó para decidirla.

Cómo se ve en la práctica: una consulta real sobre datos de Sherpa Platform

Sherpa Platform es el servicio de gestión financiera externalizada que construimos en Orbitant para un cliente. Que un modelo pueda responder preguntas sobre ventas o liquidez bancaria de una empresa concreta, sin que nadie programe esa respuesta a mano, es exactamente el escenario donde la diferencia entre tools, resources y prompts en MCP deja de ser teoría.

Para comprobarlo con código real hicimos una sesión de formación interna en la que pusimos a prueba, en directo, todo lo explicado hasta aquí contra el servidor MCP de Sherpa Platform.

Informe de ventas

La consulta de partida fue deliberadamente abierta: «Dame un informe de ventas del mes pasado», sobre datos de una empresa de demostración. Como la pregunta no menciona ninguna empresa, lo primero que hizo el modelo, sin que nadie se lo pidiera, fue llamar a la tool que lista los grupos de empresas disponibles: no sabía de qué empresa estaba pidiendo los datos y esa tool es la única forma de resolverlo.

Con la empresa ya identificada, encadenó la llamada al informe de pérdidas y ganancias —porque las ventas viven ahí— y, en la misma respuesta, una búsqueda de documentos de ventas del periodo. Todo eso ocurrió en segundos; en pantalla solo se ve la pregunta y la respuesta final.

Liquidez bancaria y gráfico

La segunda consulta pedía algo distinto —liquidez bancaria, con petición explícita de un gráfico de distribución— y el modelo respondió con otra combinación: primero la tool de liquidez bancaria, porque es la única que tiene ese dato, y después la elaboración del gráfico solicitado, porque eso es lo que se le pidió que entregara.

A ese modelo nadie le dijo qué tool llamar primero ni en qué orden combinarlas: lo dedujo del catálogo y de lo que se le preguntó. El diseño de las tools —sus nombres, sus descripciones, lo que cada una promete devolver— es lo que hizo posible esa secuencia. Ese diseño es la interfaz real con la que trabaja el modelo.

El código que falta y la grabación completa

En el siguiente artículo de la serie te contamos cómo está montado el servidor MCP de Sherpa Platform y cómo se le añade autenticación OAuth para que esta conversación tan fluida no signifique que cualquiera con la URL pueda leer los datos de cualquier empresa.

Mientras, aquí puedes ver la grabación completa, con esta misma demo en directo:

Preguntas frecuentes

¿MCP sustituye al function calling de los modelos?
Lo complementa. El function calling es la capacidad del modelo de proponer la llamada a una función; MCP estandariza cómo esa función se descubre, se expone y se ejecuta contra un sistema externo, para no reinventar esa capa de descubrimiento en cada integración.

¿Es obligatorio exponer el servidor MCP por HTTP?
Depende del caso de uso. Para desarrollo local o herramientas de escritorio, stdio es la opción habitual y no requiere autenticación adicional. Streamable HTTP entra en juego cuando el servidor tiene que ser accesible de forma remota y ahí hace falta pensar en autenticación desde el principio.

¿Qué diferencia hay entre una tool y un resource?
La tool la invoca el modelo cuando decide que necesita ejecutar una acción o consulta; el resource lo carga la aplicación, no el modelo: es contenido de solo lectura identificado por una URI. Cambia quién tiene el control sobre cuándo esa información entra en el contexto.