Tools, resources y skills en MCP: qué va en cada una al diseñar

Cuando diseñas un servidor MCP, ya no basta con decidir qué expones como tools y qué como resources. Desde que la extensión Skills de MCP es Final, también puedes servir skills, así que conviene saber qué va en cada pieza antes de escribir la primera línea. Sergio Valverde, de quien hablamos más abajo, lo formula así: las tools son lo que el agente puede hacer, los resources lo que necesita saber y las skills cómo conseguir un objetivo combinando las dos cosas.

La mecánica de la extensión (skill://, skills/list, skills/get, digests) está en Skills sobre MCP. La comparación entre skill local, servidor MCP y AGENTS.md la tienes en qué son las Agent Skills. Aquí la pregunta es de diseño: cómo repartir la funcionalidad de un servidor sin duplicar nada ni dejar huecos.

¿Cuál es la idea en una frase?

El marco más claro que hemos leído es el de Sergio Valverde en «Skills over MCP: de exponer tools a distribuir know-how» (también en LinkedIn). Su tabla asocia cada pieza a una pregunta:

Pieza	Pregunta (Valverde)	Ejemplo suyo
Tool	«¿Qué acción puedo ejecutar?»	Crear un issue
Resource	«¿Qué información necesito conocer?»	Esquema, metadata o documentación de formato
Skill	«¿Cómo consigo este objetivo?»	Crear correctamente una épica siguiendo un proceso

Es criterio del autor, no del protocolo, pero encaja con la documentación oficial. La overview de la extensión presenta las skills como útiles para “reusable workflows that combine several tools or require supporting references”. La especificación estable añade tres usos:

• Distribuir las instrucciones de uso de un servidor junto con el propio servidor.
• Flujos “too large to fit in server instructions”.
• Orquestación “that spans several tools or servers”.

La skill no es una cuarta primitiva. La extensión sirve cada archivo de la skill como un resource, que se lee con resources/read.

Esto importa ahora porque SEP-2640 se fusionó con estado Final el 13 de septiembre de 2026. Desde entonces, la fuente de verdad normativa es la especificación estable del repositorio ext-skills. Eso sí, SEP-3392 propone clasificar la extensión como Beta, una fase que admite cambios incompatibles, aunque se espera que sean raros y se documentan. Esa SEP sigue en borrador: recibió una aprobación el 7 de octubre, pero no tiene merge. Diseña contando con ello.

¿Quién decide usar cada pieza?

Es lo que más pesa en el diseño. La especificación 2026-07-28 describe para qué está pensada cada primitiva, sin imponer un modelo de interacción. La overview, por su parte, deja abierto quién elige una skill:

Pieza	Quién decide	Qué dice la fuente
Tool	El modelo	“model-controlled”, con un humano que SHOULD poder denegar invocaciones
Resource	La aplicación	“application-driven”: el host decide cómo incorporarlo (selección en la UI, búsqueda, inclusión automática)
Prompt	El usuario	“user-controlled”, típicamente como slash commands
Skill	El host decide cómo se expone	“Skills can be selected by the model based on their names and descriptions, or explicitly by the user”

Hay que hacer dos precisiones:

• Leer el SKILL.md con resources/read no activa la skill. El host la pasa por su camino de carga, que verifica el contenido y aplica la aprobación que el host exija.
• Como dice SEP-2640, “The model, not the host, decides whether to follow a skill’s instructions”.

Nuestra lectura, que no es oficial, es que la skill es un híbrido. Viaja como resource, y el patrón previsto es que la elija el modelo como si fuera una tool, mientras el host hace de portero.

¿Y en qué se diferencia de un prompt de MCP?

Ni la overview, ni la especificación estable ni la SEP comparan skills con prompts. Aparte del control (la tabla de arriba), las fuentes permiten afirmar dos diferencias:

• Forma. Un prompt es una plantilla con nombre, descripción y argumentos que prompts/get devuelve como mensajes (prompts en 2026-07-28). Una skill es un directorio con instrucciones y archivos de apoyo, con manifiesto e integridad por archivo.
• Carga y verificación. El prompt llega entero al invocarlo. La skill se carga por escalones, con digests y una aprobación ligada al conjunto, algo que los prompts no tienen.

Si tu flujo es «el agente de soporte pulsa un botón y quiere un borrador con estos dos argumentos (ticket y motivo)», sigue siendo un prompt, como responder_incidencia en la lección de prompts. Un procedimiento, en cambio, encaja mejor como skill, como recomienda la guía de la extensión. Si es «el modelo tiene que saber cómo se hace esto cuando le toque», es candidato a skill.

¿Qué criterio usamos para repartir?

Este criterio es nuestro, coherente con la overview y con Valverde. Para cada cosa que quieras exponer, pregúntate:

1. ¿Es una acción atómica, con entrada y salida claras, o tiene efectos? Tool.
2. ¿Es un dato o una referencia estable que alguien tiene que leer? Resource.
3. ¿Es una plantilla que una persona lanza a mano? Prompt.
4. ¿Es un procedimiento de varios pasos que combina tools y referencias, con decisiones y condiciones por el camino? Skill.

Valverde lo resume así: “Una operación atómica sigue siendo una buena Tool. Una especificación estable puede ser un buen Resource. Una Skill empieza a tener sentido cuando existe proceso”.

De ahí salen dos consecuencias prácticas.

No hagas una skill por tool. La especificación no define ningún campo que vincule una tool con una skill. Además, la carga dinámica de tools desde skills figura entre lo aplazado más allá de la primera versión (ext-skills#131). En la comunidad hay una pregunta abierta, sin respuesta del grupo de trabajo, que propone justo eso: que las skills no son una capa obligatoria para cada tool (ext-skills#145). Si una tool necesita una skill para usarse bien, mejora primero su descripción y su esquema. En el otro extremo, según Valverde, multiplicar tools especializadas “termina convirtiendo el servidor en una colección de endpoints cada vez más especializados”.

La skill referencia, no copia. Valverde pone el ejemplo de ADF (Atlassian Document Format), el formato de documentos de Jira. De su especificación dice: “Podría exponerse como un Resource”. Y la skill que crea una épica bien formada “no necesita duplicar toda la documentación de ADF”. El ejemplo mínimo de la documentación oficial tiene la misma forma: un SKILL.md breve que remite a un archivo de referencia, y ese archivo solo se carga si hace falta.

---
name: code-review
description: Review code using the team's checklist.
---

# Code review

Read `references/checklist.md`, then review the diff.

Código del ejemplo oficial: Skills extension overview.

Ten en cuenta un límite: una skill de un servidor no puede provocar lecturas de resources de otro servidor sin una aprobación por llamada que nombre a los dos (especificación estable). Si la skill necesita una referencia, ponla dentro de la skill o en el mismo servidor.

¿Cómo quedaría en un servidor de Nortia?

Nortia Logística es la empresa ficticia que recorre el curso. El reparto de esta tabla es ilustrativo. Las tools, los resources y el prompt existen en las lecciones de Básico, pero la skill no está en el curso como código.

Pieza	Nortia	Por qué
Tool	buscar_factura, emitir_abono (nortia-facturacion)	Acciones con entrada y salida. La segunda tiene efecto contable
Resource	pedidos://catalogo/estados, soporte://kb/{articulo}	Datos de lectura que el host incorpora cuando le conviene
Prompt	responder_incidencia (nortia-soporte)	El agente de soporte lo elige y rellena los argumentos
Skill	Un hipotético tramitar-abono con references/politica-abonos.md	Procedimiento: buscar la factura, comprobar el saldo, aplicar la política, pedir aprobación y emitir el abono

La skill no sustituye a nada. emitir_abono sigue teniendo su esquema y su error útil cuando el importe supera el saldo. El catálogo de estados sigue siendo un resource que la consola lee sin preguntar al modelo. Lo que añade la skill es el orden de los pasos y las reglas de la casa.

El caso multi-inquilino de Nortia (España y México) también apunta a servir la skill desde el servidor. La guía de archivo del grupo de trabajo, que no es normativa, cita los catálogos por rol o por inquilino entre los casos en que distribuir por MCP aporta valor.

¿Hay algún servidor real que lo haga así?

Sí. El 8 de octubre de 2026 consultamos el servidor de Hugging Face (https://huggingface.co/mcp) con peticiones 2026-07-28 reales y sin autenticar. Los datos son una medición nuestra, no una cifra del fabricante:

• server/discover declara tools, resources y la extensión con directoryRead: true. No declara prompts, y prompts/list devuelve -32601 Method not found.
• tools/list devuelve 4 tools: hf_whoami, hub_repo_search, hub_repo_details y hf_fs.
• skills/list devuelve 25 skills en una sola página, con cacheScope: "public". Algunas son grandes: skill://huggingface-llm-trainer/SKILL.md tiene 19 archivos y skill://train-sentence-transformers/SKILL.md, 31.
• Leímos skill://hf-mem/SKILL.md (3.325 bytes) y el SHA-256 que calculamos coincide con el digest y el tamaño del manifiesto.

Según su README, el servidor verifica los digests y el frontmatter de una instantánea de las skills antes de servirla, y solo anuncia la extensión si es válida.

Nuestra lectura de diseño: pocas tools primitivas que dan acceso al Hub y muchas skills que explican flujos completos, como entrenar, desplegar en SageMaker o publicar en Spaces. Esas skills combinan las tools, la CLI hf y scripts propios.

¿Una skill es un agente?

No. Valverde lo separa bien: la skill es know-how, mientras que el objetivo, el estado, la planificación, la memoria y la delegación son del agente. La especificación de la extensión apunta en la misma dirección:

• El host MUST NOT tratar una skill como contexto de más autoridad que el resto.
• Una skill no concede permisos. El campo allowed-tools del frontmatter MUST ignorarse en skills de origen MCP, salvo que el usuario haya aprobado esa concesión para esa skill.
• No hay ejecución local implícita. Nada de la skill ejecuta código en el host sin aprobación explícita del usuario para esa skill.

Para el diseño, esto significa que la skill describe el camino, pero no puede garantizar que el agente lo recorra. Lo que no puede fallar sigue en la tool y en el host, no en el texto de la skill. Por ejemplo, que el importe no supere el saldo o que el abono pase por aprobación.

¿Puedo distribuir el mismo conocimiento por varios canales?

Sí. El formato es el de Agent Skills en todos los canales, y la guía de archivo del grupo de trabajo lo dice así: “This isn’t an either/or choice. Skills can exist as local files and be served over MCP.”

Lo que cambia es la identidad. Una skill servida por MCP no puede presentarse como local, y su caché no puede estar en las rutas donde el host busca skills locales. Además, una skill de MCP MUST NOT sustituir en silencio a otra del mismo nombre (especificación estable). En la práctica, para el host, la misma skill por dos canales son dos skills distintas.

Así lo resuelven quienes ya lo hacen:

• ChatGPT importa una instantánea estática de las skills al enviar un plugin.
• fast-agent usa MCP como instalador de una copia local verificada.
• El servidor de Valverde usa una sola carpeta skills/<name>/. La sirve por la extensión y, a la vez, como Agent Plugin, dependencia APM o importación local, sin “a second editable copy”. Él lo llama «Author once, distribute many», y la frase es suya, no del proyecto.

El empaquetado en plugins (skills, servidores y configuración en un solo artefacto) queda fuera del alcance del grupo de trabajo.

¿Qué garantiza la seguridad de la extensión y qué no?

Lo que garantiza: los digests SHA-256 aseguran que lo que el host lee coincide con el manifiesto que recibió. Además, la aprobación persistida MUST atarse al conjunto completo de URIs y digests, de modo que un archivo cambiado, añadido o quitado la revoca (overview).

Lo que no garantiza: “Digests establish consistency with the server’s manifest, not trust in its content”. Los digests no van firmados y los da el mismo servidor que da el contenido. Por eso el host MUST NOT tratar una coincidencia como frontera de seguridad. Los hosts, por su parte, MUST tratar las skills servidas por MCP como “a higher-risk surface than remote tool invocation”, porque pueden dejar bytes del servidor en el host y pedir al modelo que los ejecute.

Para quien diseña el servidor, dos consecuencias:

• Agrupa los cambios. En los hosts que guardan la aprobación, cada cambio en cualquier archivo de una skill obliga a los usuarios a aprobarla otra vez.
• Evita las skills dinámicas si puedes. Con "resources": "dynamic" no hay digests estables y el host MAY rechazarlas.

No hay recomendaciones oficiales para empresas. La procedencia y la firma de skills están aplazadas (ext-skills#131), y la guía de archivo del grupo de trabajo reconoce que las preguntas de gobernanza “are still being worked out”. Valverde propone capas adicionales: orígenes permitidos, aprobación de skills, snapshots o pinning, políticas de ejecución, auditoría, promoción entre entornos y restricciones sobre contenido dinámico.

Nuestra recomendación, como criterio propio: en una empresa como Nortia, trata las skills como código. Revísalas antes de publicarlas, mantén una lista de servidores permitidos en los hosts y audita qué skill se cargó y quién la aprobó. El resto de la seguridad del servidor está en seguridad en servidores MCP.

¿Quién lo soporta hoy y qué hago mientras tanto?

A 8 de octubre de 2026, el soporte es corto:

• SDK oficiales: ninguno publicado. Hay PR abiertos en TypeScript, Python, C#, Go y Rust (lista de implementaciones). Las releases recientes, @modelcontextprotocol/server 2.3.1 (5 de octubre) y Python v2.3.0 (2 de octubre), no la incluyen.
• Clientes: la matriz oficial marca soporte en mcpc (Apify) y parcial en ChatGPT, fast-agent y MCP Inspector.
• Claude Code: la SEP lo cita como prototipo interno de Anthropic “not yet public”. Su documentación no menciona la extensión.
• MCP Inspector: verifica skills y digests desde la 2.6.0 (9 de septiembre), con mcp-inspector --cli <server> --method skills/list --verify (CLI del Inspector).

Mientras tanto, nosotros haríamos esto (criterio propio):

1. Diseña bien primero las tools y los resources, que no dependen de la extensión.
2. Escribe las skills como carpetas skills/ en el repositorio del servidor y distribúyelas también como skills locales o plugin.
3. Si sirves la extensión, apunta a las skills desde las instructions (la especificación lo permite) y compruébala con el Inspector.
4. No dependas de que el host de tus usuarios la entienda, y vigila SEP-3392.

¿Por dónde sigo?

Las tres primitivas se ven una por una en el curso, con Nortia: herramientas, recursos y prompts.

En el blog tienes el resto:

• La mecánica de la extensión, en Skills sobre MCP.
• Cómo elegir entre skill local, servidor o AGENTS.md, en qué son las Agent Skills.
• Cómo llevarlo a código, en crear un servidor MCP en TypeScript.
• Los términos, en el glosario de MCP.