Skip to content
Wayland Docs

MCP Skills via Resources

An MCP server that declares the resources capability can deliver skills to the engine without any local file deployment. The engine calls resources/list on boot, filters for URIs starting with skill://, fetches each one via resources/read, and parses the Markdown content as a normal skill. The result merges with filesystem skills from the standard load order.

The implementation is in crates/wcore-skills/src/mcp.rs.

Discovery sequence

Section titled “Discovery sequence”

load_mcp_skills runs once at boot, after the MCP client connects all configured servers:

  1. For each connected server, check supports_resources. Servers that did not advertise capabilities.resources in their initialize response are skipped without any network call.
  2. Call resources/list on the server.
  3. For each returned resource, check whether the URI starts with skill://. Non-matching URIs (for example file:// or tool://) are ignored.
  4. Call resources/read for each matching URI.
  5. Parse the returned Markdown as a skill: extract YAML frontmatter, parse recognized keys, set source = Mcp and loaded_from = Mcp.
  6. Assign a virtual path of the form <mcp:<server>:<skill_name>> for deduplication tracking. This path never matches any real filesystem path.

Failures at any step are non-fatal. If resources/list fails for one server, the remaining servers continue loading. If resources/read fails for one resource, the remaining resources on that server continue loading.

Skill URI naming

Section titled “Skill URI naming”

The skill name is derived from the server name and the URI:

ServerURISkill name
my-serverskill://my-skillmy-server:my-skill
demoskill://db/migratedemo:db:migrate
demoskill://a/b/cdemo:a:b:c

The skill:// prefix is stripped. Forward slashes in the remaining path become colons. The server name is prepended, separated by a colon.

Frontmatter

Section titled “Frontmatter”

The fetched Markdown content is parsed the same way as a local SKILL.md. Any recognized frontmatter key works: description, allowed-tools, model, effort, paths, when-to-use, and others. The name field is derived from the URI as described above; a name key in the frontmatter is ignored for MCP-sourced skills.

Example resource content an MCP server might return for skill://migrate:

---
description: Run database migrations against the current project
allowed-tools:
  - Bash
  - Read
---


Check for pending migrations with `wayland-core db status`, then run `wayland-core db migrate`.

Shell expansion (!`cmd` lines) is disabled for MCP-sourced skills. Untrusted remote sources cannot run commands through skill expansion.

Merge with filesystem skills

Section titled “Merge with filesystem skills”

After all skill sources are loaded the engine deduplicates by name. The load order, from highest priority to lowest, is:

  1. Bundled skills compiled into the binary
  2. Skills from MCP servers (this mechanism)
  3. User-global skills (<config_dir>/wayland-core/skills/)
  4. Project-local skills (.wayland-core/skills/)
  5. --add-dir paths
  6. Legacy .wayland-core/commands/ flat files

A bundled skill with the same name as an MCP skill takes precedence. An MCP skill with the same name as a user-global filesystem skill also takes precedence over the filesystem skill.

Limiting which servers expose skills

Section titled “Limiting which servers expose skills”

Skills are discovered from any server that declares capabilities.resources. To restrict skill discovery to specific servers, use the profile-level mcp_servers filter in your config:

[profiles.default]
mcp_servers = ["skills-server"]

Only servers listed in mcp_servers are active for that profile. Servers not listed are not connected, so their resources are not queried.

Next

Section titled “Next”