Entender las tres primitivas de MCP — Tools, Resources y Prompts

Cuando miras servidores MCP enseguida notas algo. Todos hablan solo de tools. Tool aquí, tool allá, «mi servidor tiene 40 tools». Y sin embargo el Model Context Protocol define tres bloques distintos que un servidor puede ofrecer, y los tools son solo uno de ellos. Los otros dos, Resources y Prompts, se ignoran casi en todas partes. Es una pena, porque resuelven justo los problemas para los que la gente, si no, abusa de los tools.

Este playbook te enseña el modelo. No como una clase sobre la especificación, sino de modo que después puedas clasificar cualquier servidor ajeno en treinta segundos y tomar la decisión correcta al construir el tuyo. Diez pasos, cada uno con un ejemplo concreto. Al final sabrás por qué un servidor de calendario ofrece «encontrar huecos libres» como tool, «mis reglas de calendario» como resource y «resumir reunión» como prompt, y por qué eso no es casualidad.

Paso 1, la única pregunta que lo decide todo

Recuerda una pregunta y habrás entendido todo el modelo: ¿quién decide que este bloque se está usando ahora mismo? Hay tres respuestas posibles y exactamente tres primitivas.

Los tools son model-controlled. El modelo mismo decide en mitad de una respuesta, ahora llamo a esto. Las resources son application-controlled. La aplicación de alrededor, es decir Claude Code o un cliente de chat, decide si se cargan y cuándo. Los prompts son user-controlled. La persona los selecciona activamente, normalmente a través de un menú o un slash command.

Estos tres niveles de control son todo el truco. Cuando dudes al construir qué bloque coger, pregúntate simplemente quién debe tener el control. La respuesta te muestra la primitiva.

Paso 2, los Tools son acciones que el modelo elige

Un tool es una función que el modelo puede llamar para hacer algo o para consultar algo. Consultar el tiempo, escribir un archivo, crear una factura en el CRM, arrancar una búsqueda. El modelo lee la descripción del tool, decide por sí mismo si encaja, y lo llama con argumentos.

Lo decisivo es la autonomía. Dices «créame el cliente Meier» y el modelo elige el correcto entre veinte tools, rellena los campos y dispara. Nadie dijo de antemano qué tool. Por eso es model-controlled.

Como los tools pueden desencadenar acciones que tienen consecuencias reales, necesitan una confirmación antes de ejecutarse en casi cualquier cliente. Esa es la razón por la que Claude Code te pregunta antes de un tool de escritura. Un tool puede enviar un correo o cambiar una fila en una base de datos, y eso no debe pasar en silencio.

Paso 3, por qué todos construyen solo Tools

Los tools son lo primero que aprende cualquiera, son lo más fácil de explicar, y sinceramente con tools solos ya se puede construir casi todo. Justo eso es la trampa. Como los tools son tan potentes, la gente lo mete todo en tools, incluidas cosas que en realidad serían resources o prompts.

Un ejemplo típico. Alguien construye un tool llamado get_company_guidelines que siempre devuelve el mismo bloque de texto, las directrices de la empresa. El modelo primero tiene que llamar activamente al tool, cuesta un roundtrip, y está ahí ocupando sitio en la lista de tools y distrae. Y sin embargo unas directrices estáticas son el caso de manual para una resource. Quien conoce las tres primitivas lo hace más limpio.

Paso 4, las Resources son contexto que la aplicación carga

Una resource es un trozo de contexto que el servidor provee y que la aplicación puede traer a la conversación. Un archivo, un extracto de base de datos, un log, una configuración, una imagen. Las resources se identifican mediante una URI, algo como file:///projekt/readme.md o db://kunden/meier.

La diferencia con un tool es el control. Con una resource no decide el modelo, sino la aplicación, si el contenido se carga y cuándo. En la práctica eso suele significar que el usuario hace clic en «adjuntar esta resource» en un menú, o la aplicación la trae automáticamente porque encaja con el contexto. El modelo recibe entonces el contenido servido, no lo fue a buscar él mismo.

¿Por qué es esto mejor que un tool que entrega el mismo texto? Porque una resource no cuesta ningún roundtrip y no exige ninguna decisión del modelo. Simplemente está ahí, marcada limpiamente como contexto. Para todo lo que es material de consulta y no una acción, la resource es la opción correcta.

Paso 5, el ejemplo del calendario para Resources

Imagínate un servidor de calendario. «Mi disponibilidad las próximas dos semanas» es una resource. Es contexto, no desencadena ninguna acción, y la aplicación puede colgarla en una conversación cuando se trata de planificar citas.

La diferencia fina con un tool. «Encontrar huecos libres entre dos fechas» sería un tool, porque el modelo calcula y filtra activamente con parámetros. «Aquí está mi calendario completo como contexto» es una resource, porque solo provee material. El mismo tema, dos bloques distintos, según se actúe o se consulte.

Paso 6, los Prompts son plantillas que la persona arranca

Un prompt en el sentido de MCP no es el texto que tecleas. Es una plantilla predefinida o un flujo de trabajo que el servidor ofrece y que el usuario selecciona a conciencia. En muchos clientes aparecen como slash commands o en un menú con las acciones disponibles.

Ese es el bloque user-controlled. La persona dice «quiero ahora el flujo de code review», elige el prompt, quizá introduce un par de parámetros, y el servidor devuelve una instrucción ya estructurada que pone la conversación en marcha. El modelo no eligió el prompt por sí mismo, ni la aplicación tampoco, sino tú.

Un prompt puede unir resources y tools. El prompt «resumir reunión» quizá trae la transcripción como resource y al final llama a un tool que guarda el resumen. Los prompts son por eso a menudo el paréntesis alrededor de todo un flujo.

Paso 7, las tres una junto a la otra en un servidor

Coge el servidor de calendario otra vez y superpón las tres primitivas, entonces ves el patrón.

Tool, encontrar huecos libres, el modelo decide y calcula. Resource, mis reglas de calendario y mis próximas dos semanas, contexto que la aplicación adjunta. Prompt, planifícame una reunión con el equipo X, un flujo que arranco como persona y que por dentro lee la resource y al final dispara el tool.

Esto no es un constructo académico. Un servidor bien pensado usa a conciencia las tres, y quien ve el reparto entiende al instante cómo está pensado el servidor. Quien solo ve tools sabe, aquí alguien dejó de lado los otros dos bloques.

Paso 8, así clasificas un servidor ajeno

Cuando conectas un servidor MCP nuevo, mira qué ofrece y ordénalo en la cabeza. La mayoría de clientes te muestran los tools de todos modos, muchos también los prompts como slash commands, y las resources suelen aparecer en un menú de adjuntar.

Con cada entrada pregúntate, qué es esto. ¿Desencadena una acción, model-controlled? entonces tool. ¿Es material de consulta que se trae dentro, application-controlled? entonces resource. ¿Es un flujo que arrancas tú mismo, user-controlled? entonces prompt. Después de tres o cuatro servidores lo haces automáticamente y entiendes los servidores ajenos mucho más rápido.

Paso 9, la regla de diseño para construir el tuyo

Cuando construyas un servidor tú mismo, toma la decisión a conciencia en lugar de convertirlo todo en tools por reflejo. La regla general es corta.

¿Actúa? coge un tool. ¿Es contexto estático o consultable sin efecto secundario? coge una resource. ¿Es un flujo recurrente que inicia una persona? coge un prompt. Si notas que un tool en realidad solo devuelve siempre el mismo texto, esa es una señal fuerte de que debería ser una resource. Y si quieres quitarle al usuario un flujo complejo de varios pasos, mételo en un prompt en lugar de esperar que el modelo componga los pasos bien por sí solo.

Un efecto secundario de esta limpieza es menos tool sprawl. Cada tool que en realidad es una resource atasca la lista de tools y le hace más difícil la elección al modelo. Menos tools, más certeros, más resources en condiciones, más un par de prompts, eso es un servidor que se siente bien.

Paso 10, qué soportan de verdad los clientes

Un apunte honesto para terminar. No todos los clientes manejan las tres primitivas igual de bien. Tools los soporta prácticamente todo el mundo. Los prompts como slash commands están muy extendidos. Las resources no se hacen igual de visibles en todas partes, algunos clientes las muestran de forma prominente, otros apenas.

Para ti eso significa, construye tu servidor limpio con las tres primitivas, pero en lo más importante no te fíes de que cada cliente muestre también la resource. La funcionalidad central que tiene que correr sí o sí va en tools, porque esos funcionan en todas partes. Resources y prompts son el remate que redondea tu servidor donde el cliente juega. Qué puede hacer cada cliente está en el resumen oficial de clientes, y ese cambia rápido, así que míralo una vez antes de fiarte de una funcionalidad.

Qué viene ahora

Ahora tienes el modelo en la cabeza y puedes clasificar servidores. El siguiente paso lógico es construir uno tú mismo. Para eso está el playbook Tu primer servidor MCP en 90 minutos, donde viertes todo esto en código. Si tu servidor luego corre pero el cliente no lo muestra limpiamente, ayuda Depurar MCP cuando nada funciona. Y la base conceptual de por qué MCP está construido así está en el Nivel 4, lección Qué es MCP.

Fuentes

• Model Context Protocol, Understanding MCP servers (Tools, Resources, Prompts y sus modelos de control): https://modelcontextprotocol.io/docs/learn/server-concepts
• Model Context Protocol, especificación oficial: https://modelcontextprotocol.io/specification