Skills sobre MCP: la nueva extensión oficial explicada

La extensión Skills de MCP (io.modelcontextprotocol/skills, SEP-2640) es la forma oficial de servir skills desde un servidor MCP. El servidor expone cada archivo de una skill como un recurso con URI skill://, y el host las descubre con skills/list y skills/get. El formato de la skill lo define la especificación de Agent Skills, no MCP.

Entre agosto y octubre de 2026 no salió ninguna versión nueva de la especificación de MCP. La única novedad normativa del periodo fue esta: SEP-2640 se fusionó el 13 de septiembre de 2026 con estado Final. Si mantienes un servidor que ya reparte instrucciones o procedimientos a los agentes, o un host que los consume, te conviene saber qué fija exactamente y qué deja abierto.

Qué es la extensión Skills

Una skill es una carpeta con un SKILL.md y, si hace falta, scripts/, references/ y assets/. El SKILL.md lleva un frontmatter YAML con name y description, y debajo las instrucciones en Markdown.

La skill funciona por divulgación progresiva, en tres escalones (especificación de Agent Skills):

1. El agente carga primero los metadatos (unos 100 tokens).
2. Cuando activa la skill, carga el cuerpo del SKILL.md (se recomiendan menos de 5.000 tokens).
3. Por último carga los recursos, solo si los necesita.

Si quieres el formato en detalle y cuándo conviene una skill frente a un servidor MCP, lo tienes en qué son las Agent Skills.

La especificación de Agent Skills define el formato, pero no cómo se distribuye una skill. La extensión cubre esa otra parte. Fija cómo las sirve un servidor MCP remoto, para que cualquier host que hable la extensión pueda descubrirlas y leerlas.

Datos de la ficha (SEP-2640):

Como toda extensión oficial, vive fuera del núcleo del protocolo y está desactivada por defecto. Solo entra en juego si el servidor la declara y el host la entiende. Cómo se negocian las extensiones y qué pasa si solo una parte las soporta lo explicamos en la lección «Interacción con el usuario y extensiones» del curso.

Qué define y qué delega

La SEP deja claro el reparto. Todo el formato de la skill, es decir, la estructura de carpetas, el frontmatter, los nombres y la divulgación progresiva, “is delegated entirely to the Agent Skills specification; this SEP defines only the transport binding” (SEP-2640).

Lo que sí define la extensión:

• Recursos. Cada archivo de una skill es un recurso MCP, normalmente bajo el esquema skill://. Se lee con el resources/read de siempre. Si no tienes claro cómo funcionan los recursos en la versión actual, la lección «Recursos» del curso es el punto de partida.
• Dos métodos obligatorios: skills/list y skills/get.
• Un método opcional: resources/directory/read, solo si el servidor declara directoryRead: true.
• Integridad: digests SHA-256 por archivo en cada entrada de skills/list (lo vemos abajo).

Hay un matiz de versión. La extensión está escrita contra la revisión 2026-07-28, y en esa revisión skills/list incorpora los atributos de caché de listas de SEP-2549 (SEP-2640).

No la confundas con Agent Plugins 1.0, que Vercel publicó el 6 de agosto de 2026 junto con AWS, Anysphere, GitHub, Microsoft y OpenAI. Agent Plugins es un formato de empaquetado (plugin.json + skills/ + mcp.json) para distribuir servidores MCP y skills juntos. La extensión Skills no empaqueta nada. Define cómo un servidor en marcha ofrece skills por el protocolo.

Declarar la capacidad y listar skills

El servidor anuncia la extensión dentro de sus capacidades, en el mapa extensions. Además debe declarar la capacidad resources, porque los archivos se sirven como recursos (overview de la extensión).

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol/skills": {
        "directoryRead": true
      }
    }
  }
}

Ejemplo literal de SEP-2640: declaración de capacidad.

Con directoryRead: true el servidor se compromete a atender resources/directory/read. Si no lo pones, el host no debe contar con ese método.

El host pide la lista con skills/list:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "skills/list",
  "params": {}
}

Ejemplo literal de SEP-2640: petición de skills/list.

Igual que los ejemplos de la propia especificación, este omite el _meta. En la red, una petición 2026-07-28 lleva siempre en _meta la versión del protocolo y las capacidades del cliente.

Y esta es la primera entrada de la respuesta del ejemplo de la SEP (el original incluye dos skills más):

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "resultType": "complete",
    "skills": [
      {
        "uri": "skill://git-workflow/SKILL.md",
        "frontmatter": {
          "name": "git-workflow",
          "description": "Follow this team's Git conventions for branching and commits"
        },
        "resources": [
          {
            "uri": "skill://git-workflow/SKILL.md",
            "digest": "sha256:a1b2c3d4...",
            "size": 2314
          }
        ]
      }
    ]
  }
}

Fragmento literal de SEP-2640: respuesta de skills/list.

Fíjate en tres cosas. El frontmatter viaja en la lista, así que el host tiene los metadatos de cada skill (el primer escalón de la divulgación progresiva) sin leer ningún archivo. La uri apunta al SKILL.md, que se lee después con resources/read. Y cada archivo de resources trae su digest y su size.

sequenceDiagram
  participant H as Host
  participant S as Servidor MCP
  participant U as Usuario
  H->>S: skills/list
  S-->>H: skills: uri, frontmatter, resources con digest
  H->>S: resources/read skill://git-workflow/SKILL.md
  S-->>H: contenido del SKILL.md
  Note over H: Compara el SHA-256 con el digest
  H->>U: Pide aprobación para ese conjunto
  U-->>H: Aprueba
  Note over H,U: Si cambia el conjunto, se revoca

Seguridad: digests y aprobación ligada al conjunto

Una skill es texto que dirige lo que hace el agente. Si el servidor puede cambiar un SKILL.md sin que nadie se entere, puede cambiar el comportamiento del agente sin que nadie se entere. La extensión ataca eso con dos reglas (SEP-2640):

1. Cada entrada de skills/list incluye un digest SHA-256 por archivo, y el host debe verificarlos.
2. La aprobación del usuario queda ligada al conjunto exacto de recursos. Si ese conjunto cambia, la aprobación se revoca.

Si escribes un host, no basta con pedir permiso la primera vez que el usuario activa una skill. Tienes que verificar los digests de lo que lees, guardar a qué conjunto de recursos dio permiso el usuario y volver a pedirlo cuando ese conjunto cambie.

Si escribes un servidor, cada cambio en el conjunto de recursos de una skill obliga a los usuarios a aprobarla otra vez. Por eso conviene agrupar los cambios.

Quién la soporta hoy

Poco, y la documentación oficial lo dice sin rodeos: “SDK and host support is still being implemented” (overview de la extensión).

La matriz de soporte por cliente, que la documentación amplió con la extensión Skills el 8 de septiembre de 2026, marca:

El PR de la SEP cita varias implementaciones de referencia:

• los SDK de TypeScript, Python, C# y Go
• prototipos de host en gemini-cli, fast-agent, goose, codex y Claude Code
• el GitHub MCP Server.

Fíjate en la palabra. Son implementaciones de referencia y prototipos citados en el PR, no soporte publicado en esos productos. A 8 de octubre de 2026, la sección «Reference Implementation» de la página de la SEP solo enlaza Python, C# y Go. Ningún SDK oficial ha publicado la extensión (los de TypeScript, Python, C#, Go y Rust tienen PR abiertos). De Claude Code, la SEP solo dice «prototyped internally at Anthropic; not yet public».

Del lado de los servidores, la única cifra que hemos encontrado es de un tercero: según API Evangelist, a 22 de septiembre solo 2 de los 572 servidores MCP que respondieron a su sondeo declaraban la extensión, uno de ellos el de Hugging Face. No es un dato oficial, pero encaja con lo que dice la propia documentación.

Cómo probarla con el Inspector

El MCP Inspector publicó una versión por semana durante el periodo, de la 2.1.0 a la 2.9.0, y entre lo que añadió está la verificación de skills (releases del Inspector). La matriz oficial le da soporte parcial.

Es la herramienta natural para comprobar un servidor propio antes de que lo consuma un host real. Te permite ver que declara la extensión, que skills/list devuelve lo que esperas y que los digests cuadran con lo que sirve resources/read. Como ese soporte es parcial, revisa las notas de versión de la release que instales para saber qué parte de la extensión cubre. El uso general del Inspector y de los tests de conformidad se ve en el nivel Avanzado del curso.

Qué viene: SEP-3392 la propone como Beta

Final no significa lo mismo que estable para siempre. El 25 de septiembre de 2026 se abrió SEP-3392 (Extension Lifecycle), un borrador que propone tres fases para las extensiones (Experimental, Beta y Stable) o su promoción al núcleo. La clasificación que propone:

• ext-apps y ext-auth: Stable
• ext-skills y ext-tasks: Beta
• ext-server-card: Beta cuando se acepte SEP-2127, que se fusionó el 6 de octubre de 2026.

Es un borrador, así que la clasificación puede cambiar. Aun así, describe bien el momento: la extensión Skills tiene el texto cerrado y la adopción por hacer.

Cómo encaja esto con el calendario de la próxima versión de la especificación lo explicamos en la próxima versión de MCP. Y dónde queda Skills frente a A2A, AGENTS.md y el resto de piezas, en el mapa de protocolos de agentes de IA.

Nuestra recomendación si mantienes un servidor y ya distribuyes procedimientos como prompts o como recursos sueltos: prueba a servirlos como skills con la extensión. Usa el Inspector como cliente de prueba y no dependas todavía de que los hosts de tus usuarios la entiendan.

Si mantienes un host, empieza por lo que no cambiará aunque la extensión pase a Beta. Es decir, verificar digests y atar la aprobación al conjunto exacto de archivos.

Si estás diseñando un servidor y dudas qué convertir en tool, en resource o en skill, tienes el criterio en tools, resources y skills en MCP.