Skills Guías
En esta página
Básico Lección 4 de 17 ≈ 35 min de lectura
Especificación 2026-07-28
Recursos
Especificación MCP 2026-07-28 · revisada el 2 de octubre de 2026
Qué es un resource de MCP y quién decide usarlo, cómo se listan y se leen con sus mensajes completos, cómo se cachean con ttlMs y cacheScope y cómo se reciben sus cambios.
Qué aprenderás
- Decidir qué datos de un sistema se exponen como resource y explicar quién los lee y cuándo
- Diseñar URIs y plantillas de URI para un dominio propio
- Leer y escribir los mensajes de resources/list, resources/templates/list y resources/read, incluido el error de resource no encontrado
- Elegir ttlMs y cacheScope para un resource según quién puede verlo y cada cuánto cambia
- Registrar un resource fijo y uno con plantilla en TypeScript y en Python
Contenido de la lección
- 01 El problema
- 02 Qué es un resource y quién lo usa
- 03 Listar, descubrir plantillas y leer
- 04 Contenido de texto, contenido binario y resource inexistente
- 05 Frescura: caché y avisos de cambio
- 06 Registrar resources en el servidor
- 07 En producción
Además: quiz de comprobación y desafío práctico.
Extracto
Una agente de soporte de Nortia abre el ticket TCK-88213: un cliente pregunta por qué no ha llegado el pedido PED-2026-004812. La consola de soporte lleva un asistente que redacta un borrador de respuesta. Para que ese borrador sirva, el modelo necesita la ficha del pedido y saber qué significa cada estado de envío.
Una opción es dejar que lo pida el modelo. Ve una tool buscar_pedido, decide llamarla y espera el resultado. Funciona, pero cuesta una ronda más de modelo en cada ticket y depende de que el modelo decida hacerlo. En cambio, la consola ya sabe qué pedido es, porque el identificador está en el ticket. No hay nada que decidir.
Fin del extracto · la lección sigue con 6 secciones más
Artículos relacionados
Preguntas frecuentes
¿Qué es un resource (recurso) en MCP?
Es un dato de solo lectura que un servidor MCP identifica con una URI, como la ficha de un pedido o un catálogo de estados, y que se enumera con resources/list y se obtiene con resources/read. A diferencia de una tool, no lo elige el modelo: lo pide la aplicación por su cuenta, por ejemplo porque la persona lo ha adjuntado o porque la vista en la que está lo necesita, así que se sabe con exactitud qué contexto recibió el modelo. El protocolo no ofrece ninguna operación para modificar un resource.
¿Qué son `ttlMs` y `cacheScope` en MCP?
Son dos campos obligatorios en los resultados de los listados, de las lecturas de resources y de server/discover que dicen cómo se puede cachear la respuesta: ttlMs indica cuántos milisegundos se considera fresca desde que llega (0 equivale a caducada al instante) y cacheScope indica quién puede reutilizarla. Con "public" puede guardarla y reutilizarla cualquiera, gateways y proxies incluidos, porque no contiene datos de un usuario; con "private" solo vale para quien presentó la misma autorización. Ninguno de los dos controla el acceso: el servidor sigue comprobando los permisos en cada petición.
¿Cómo se entera un cliente MCP de que un resource ha cambiado?
Enviando una petición subscriptions/listen, que el servidor contesta con un stream abierto; por él llegan solo los avisos que el cliente pidió en params.notifications, por ejemplo cambios en las URIs que enumeró en resourceSubscriptions. El aviso no incluye el contenido nuevo: invalida la copia guardada y el cliente vuelve a llamar a resources/read cuando le hace falta. En la versión 2026-07-28 desaparecen los métodos resources/subscribe y resources/unsubscribe.