Comparación de Herramientas, Recursos y Prompts de MCP
Cada capacidad que agregas a un servidor MCP debe convertirse en una Herramienta (Tool), un Recurso (Resource) o un Prompt, y elegir la correcta mantiene tu servidor predecible para cada cliente que se conecta a él.
Esta página recorre las decisiones que encontrarás con más frecuencia al diseñar un servidor y clasifica la opción correcta para cada una.
Cómo Usar Esta Comparación
- Lee cada escenario y verifica qué primitiva coincide con la forma de lo que estás construyendo, no solo con lo que se siente conveniente codificar primero.
- Cuando una capacidad pueda encajar plausiblemente en dos primitivas, prefiere aquella cuyos semánticas (acción vs. datos vs. instrucción) coincidan con el modelo mental del lector sobre lo que está sucediendo.
- Revisa estas decisiones a medida que un servidor crece; una capacidad que comenzó como una herramienta a veces revela un recurso o prompt más limpio debajo de ella.
- Trata las entradas de "Elección incorrecta" como errores reales que vale la pena evitar, no solo como casos extremos teóricos.
Decisión 1: Obtener el contenido de un archivo
Escenario: Un servidor necesita permitir a un cliente leer el contenido de un archivo específico en disco.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Recurso | @mcp.resource("file://{path}") aborda el archivo por URI y devuelve su contenido al leerlo |
| 2º | Herramienta | Una herramienta read_file(path: str) funciona, pero oculta el hecho de que es una lectura pura y almacenable en caché |
| 3º | Prompt | No es adecuado; los prompts producen instrucciones, no contenido de archivo sin procesar |
Elección incorrecta: Construir esto como una herramienta llamada get_file_action que también registra una entrada de auditoría como efecto secundario, ya que eso mezcla una lectura con una escritura dentro de algo que los clientes asumirán que es seguro llamar repetidamente.
Por qué la mejor es la mejor: Un recurso hace explícita la naturaleza de solo lectura y permite a cualquier cliente almacenarlo en caché o listarlo sin adivinar efectos secundarios.
Decisión 2: Crear un nuevo registro en una base de datos
Escenario: Un servidor necesita permitir que el modelo cree una nueva fila, como una tarea o un ticket.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Herramienta | Una herramienta create_task(title: str, priority: str) realiza la inserción y devuelve el nuevo id |
| 2º | Recurso | No es apropiado; los recursos no deben mutar el estado |
| 3º | Prompt | No es adecuado; una base de datos no puede realizar una escritura en una base de datos |
Elección incorrecta: Exponer la creación como una URI de recurso como tasks://create?title=X, ya que las lecturas de recursos deben ser idempotentes y libres de efectos secundarios, y un cliente podría volver a leerla sin esperar una nueva fila cada vez.
Por qué la mejor es la mejor: Una herramienta señala claramente "esto realiza una acción", y el modelo entiende que llamarla de nuevo puede crear un segundo registro.
Decisión 3: Estandarizar cómo el modelo resume un documento
Escenario: Múltiples clientes necesitan que el modelo resuma documentos de la misma manera exacta cada vez.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Prompt | Una plantilla de prompt summarize_document empaqueta las instrucciones exactas y las reglas de formato una vez |
| 2º | Herramienta | Una herramienta summarize(text: str) podría funcionar si la lógica de resumen en sí se ejecuta en el servidor, no a través del modelo |
| 3º | Recurso | No es adecuado; los recursos contienen datos, no instrucciones |
Elección incorrecta: Confiar en que cada cliente escriba su propia instrucción ad hoc "por favor, resume esto", ya que la deriva en la redacción entre clientes produce resúmenes inconsistentes incluso para el mismo documento. Por qué la mejor es la mejor: Un Prompt es exactamente la primitiva diseñada para instrucciones compartidas y versionadas que múltiples clientes invocan de manera consistente.
Decisión 4: Exponer la configuración actual del servidor
Escenario: Un servidor tiene configuraciones (flags de características, límites, valores predeterminados) que un cliente o modelo puede necesitar ver.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Recurso | Un recurso estático config://settings devuelve la configuración actual como JSON |
| 2º | Herramienta | Una herramienta get_config() funciona, pero implica una acción para lo que en realidad es una lectura estática |
| 3º | Prompt | No es adecuado; la configuración son datos, no instrucciones |
Elección incorrecta: Codificar valores de configuración en cada plantilla de prompt en lugar de exponerlos como un recurso, lo que significa que cada plantilla tiene que ser editada cada vez que cambia una configuración. Por qué la mejor es la mejor: Un recurso es el lugar natural para cualquier cosa que sea "estado actual para leer", especialmente cuando rara vez o nunca tiene efectos secundarios.
Decisión 5: Enviar una notificación o realizar una llamada externa
Escenario: El modelo necesita enviar un correo electrónico, publicar un mensaje o llamar a una API externa que cambie algo fuera del servidor.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Herramienta | Una herramienta send_email(to: str, subject: str, body: str) realiza la llamada e informa éxito o fracaso |
| 2º | Recurso | No es apropiado; esta es una acción con efectos secundarios en el mundo real |
| 3º | Prompt | No es adecuado; un prompt no puede realizar una llamada externa por sí solo |
Elección incorrecta: Construir esto como un recurso que "envía" en cada lectura, ya que un cliente que vuelve a leer un recurso (para caché o visualización) activaría inesperadamente un segundo envío. Por qué la mejor es la mejor: Una herramienta hace explícita la acción, y el modelo trata cada llamada como algo con una consecuencia real en lugar de una lectura segura y repetible.
Decisión 6: Guiar un flujo de trabajo de revisión de código de varios pasos
Escenario: Un equipo quiere que cada cliente ejecute la revisión de código de la misma manera, con la misma lista de verificación y tono.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Prompt | Un prompt code_review con argumentos para el diff y las áreas de enfoque produce instrucciones consistentes |
| 2º | Herramienta | Una herramienta run_static_analysis(path: str) podría complementar el prompt para las partes mecánicas de la revisión |
| 3º | Recurso | No es adecuado por sí solo, aunque las pautas de revisión también podrían exponerse como un recurso para referencia |
Elección incorrecta: Pegar la lista de verificación de revisión en el prompt del sistema de cada cliente por separado, ya que las actualizaciones luego deben realizarse en varios lugares y desincronizarse.
Por qué la mejor es la mejor: Un Prompt centraliza la instrucción en el servidor, por lo que cada cliente que invoca code_review obtiene la versión actual automáticamente.
Decisión 7: Permitir que el modelo busque un registro de cliente específico
Escenario: Una herramienta de soporte necesita que el modelo busque el registro de un cliente por id.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Recurso | customers://{customer_id} aborda cada registro por una URI estable y almacenable en caché |
| 2º | Herramienta | Una herramienta get_customer(customer_id: str) funciona si la búsqueda también necesita aplicar reglas de acceso dinámicas por llamada |
| 3º | Prompt | No es adecuado; los prompts no obtienen datos |
Elección incorrecta: Construir una única herramienta search_customers que siempre devuelva todos los campos coincidentes independientemente de lo que el modelo necesite realmente, ya que eso filtra más datos en el contexto de lo necesario.
Por qué la mejor es la mejor: Un recurso indexado por id proporciona una forma predecible, mínima y direccionable de obtener exactamente un registro.
Decisión 8: Forzar un formato de salida específico en cada cliente
Escenario: Varias aplicaciones cliente necesitan que el modelo siempre responda a un tipo de solicitud determinado en una forma JSON fija.
| Rango | Elección | Enfoque |
|---|---|---|
| Mejor | Prompt | Una plantilla de prompt con instrucciones explícitas de formato de salida, invocada de la misma manera por cada cliente |
| 2º | Herramienta | La salida estructurada de la herramienta puede forzar el formato si el formato ocurre en el código en lugar de en la salida del modelo |
| 3º | Recurso | No es adecuado; los recursos no dan forma a la salida del modelo |
Elección incorrecta: Confiar en que los desarrolladores de cada cliente recuerden y copien las instrucciones de formato exactas en sus propios prompts, ya que incluso pequeñas diferencias en la redacción producen formas de salida inconsistentes. Por qué la mejor es la mejor: Un Prompt compartido garantiza que cada cliente envíe al modelo las mismas instrucciones de formato, byte por byte.
Aplicación de Esta Comparación en la Práctica
- Comienza preguntando si la capacidad cambia algo: si es así, es una Herramienta; si es puramente una lectura, considera primero un Recurso.
- Utiliza un Prompt solo cuando la consistencia de la redacción entre múltiples clientes sea el problema real que estás resolviendo, no solo porque quieras ahorrar unas pocas líneas de texto.
- La mayoría de los servidores de producción utilizan las tres primitivas juntas: Herramientas para acciones, Recursos para los datos que esas acciones tocan, y Prompts para las instrucciones que las unen de manera consistente.
Preguntas Frecuentes
¿Cuál es la pregunta más importante al elegir una primitiva?
¿Esta operación cambia algo? Si es así, es una Herramienta. Si solo lee datos existentes, considera un Recurso. Si está empaquetando instrucciones reutilizables en lugar de datos o una acción, es un Prompt.
¿Puede una capacidad ser legítimamente construida como una Herramienta o un Recurso?
A veces, como una búsqueda de datos que podría ser un recurso parametrizado o una herramienta de solo lectura. Prefiere el Recurso cuando los datos tienen una forma genuinamente estática y son direccionables; prefiere la Herramienta cuando la búsqueda necesita lógica por llamada, como verificaciones de autorización dinámicas.
¿Por qué no hacer todo una Herramienta por simplicidad?
Hacer todo una herramienta oculta qué operaciones son lecturas seguras y cuáles tienen efectos secundarios, lo que hace que el servidor sea más difícil de razonar y puede llevar al modelo a tratar acciones destructivas tan casualmente como una búsqueda.
¿Cuándo vale la pena el esfuerzo de diseño adicional de un Prompt?
- Cuando más de un cliente necesita la redacción exacta de la misma instrucción.
- Cuando deseas versionar y actualizar instrucciones en un lugar en lugar de muchos.
- Cuando la consistencia del formato de salida es importante en todo un equipo o producto.
¿Cuál es el error más común que cometen los equipos al diseñar su primer servidor MCP?
Construir cada capacidad como una herramienta, incluso las lecturas puras, porque las herramientas son el análogo más obvio a la llamada de funciones. Esto entierra las búsquedas de datos seguras y almacenables en caché dentro de la misma primitiva que las acciones destructivas.
¿Deben los valores de configuración ser un Recurso o estar codificados en los Prompts?
Un Recurso. Codificar la configuración en cada plantilla de prompt significa que cada cambio de valor requiere editar múltiples plantillas en lugar de un único manejador de recursos.
¿Es alguna vez correcto no tener Prompts en un servidor?
Sí. Muchos servidores útiles exponen solo Herramientas y Recursos; los Prompts valen la pena agregarlos específicamente cuando la consistencia de la redacción entre múltiples clientes se convierte en un problema real y observado.
¿Cómo suelen funcionar juntas las Herramientas y los Recursos?
Una Herramienta a menudo crea o actualiza datos, y un Recurso luego expone esos mismos datos para su lectura posterior, indexados por el id que devolvió la herramienta.
¿Cuál es el riesgo de usar un Recurso para algo con efectos secundarios?
Los clientes pueden asumir que los recursos son seguros para leer repetidamente o para almacenar en caché. Un recurso con un efecto secundario oculto puede desencadenar acciones repetidas no deseadas, como el envío de notificaciones duplicadas.
¿Cómo debo decidir entre una Herramienta de búsqueda y un Recurso de búsqueda?
Si la búsqueda es una lectura directa de id a registro, usa un Recurso. Si necesita lógica personalizada por llamada, como filtrar por los permisos del usuario actual, una Herramienta te da más espacio para ejecutar esa lógica antes de devolver un resultado.
¿Necesitan las tres primitivas ser descubribles por el cliente?
Sí. Los clientes llaman a list_tools(), list_resources() (y list_resource_templates()), y list_prompts() para descubrir lo que ofrece un servidor, independientemente de las primitivas que utilice.
¿Puede un Prompt hacer referencia a un Recurso dentro de sus mensajes generados?
Una plantilla de prompt se puede escribir para incluir la URI o el contenido de un recurso como parte de sus instrucciones generadas, brindando al modelo tanto una redacción consistente como datos relevantes en una sola invocación.
Relacionado
- Comprendiendo MCP: Herramientas, Recursos y Prompts - la base conceptual detrás de cada primitiva.
- Definición de Herramientas Invocables en un Servidor MCP - diseño de esquemas y manejadores para herramientas.
- Exposición de Datos Legibles como Recursos MCP - diseño de URI para recursos.
- Creación de Plantillas de Prompt Reutilizables con Prompts MCP - diseño de prompts compartidos y parametrizados.
- Mejores Prácticas de Conceptos Centrales de MCP - una lista de verificación para aplicar estas decisiones de manera consistente.
Versiones de Stack: Escrito contra la línea de modelos Claude actual a partir de ~junio de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (el predeterminado), y Claude Haiku 4.5 - y la especificación actual del Protocolo de Contexto del Modelo. Los nombres de los modelos, las versiones del SDK y la especificación MCP cambian rápidamente; verifica los detalles actuales en platform.claude.com/docs y modelcontextprotocol.io antes de confiar en ellos.