Honor enabled: false in SKILL.md frontmatter during skills discovery

[ZeTioZ]

Enhancement

Summary

FastMCP skills discovery currently exposes any directory containing a SKILL.md, even when the skill frontmatter contains enabled: false.

It would be useful for SkillsDirectoryProvider (and the convenience skills providers built on top of it) to honor an enabled frontmatter flag and skip disabled skills during discovery.

That makes it hard to keep skills installed in a repository or user skills directory while intentionally hiding some of them from MCP clients. In practice, teams may want to:

• keep draft or experimental skills in the filesystem
• temporarily disable problematic skills without deleting them
• ship a shared skills directory where only a subset should be discoverable
• use the same SKILL.md metadata model for both descriptive fields and enable/disable lifecycle control

A disabled skill still being listed as an MCP resource can create client-side confusion, because the skill looks available even though the project or maintainer considers it inactive.

For example:

---
name: my-skill
description: Experimental skill
enabled: false
---

With the current behavior, this skill is still discovered and exposed.

The expected behavior would be for it to be ignored by discovery until enabled is removed or set to true.

Proposed Implementation

Honor an enabled frontmatter field during skills discovery, with behavior similar to:

• missing enabled => treated as enabled
• enabled: true => discovered normally
• enabled: false => excluded from discovery

This could be implemented in SkillsDirectoryProvider after loading/parsing the skill metadata for each candidate directory.

A minimal version would be enough:

• parse frontmatter as today
• if enabled is explicitly false, skip registering that SkillProvider

Additional context

We ran into this while integrating FastMCP skills discovery in a wrapper/server layer and had to add custom filtering downstream to avoid exposing disabled skills to clients.

[jlowin]

Thanks for the thoughtful write-up. Skills over MCP is still highly experimental — there's an active MCP working group focused on how skill discovery and lifecycle should work at the protocol level. Until that settles, we'd rather not introduce FastMCP-specific conventions (like enabled frontmatter) that might diverge from whatever the spec lands on.

For now, the simplest approach is to control which directories you point SkillsDirectoryProvider at, or filter downstream in your wrapper layer as you're already doing.

Closing this as not planned for the time being, but we'll revisit as the skills spec matures.