albedo
small gleam coding and persistent agent daemon with a detachable cli and a canvas ui albedo.sh
Star 115
Fork 23
Watch

skills over MCP (SEP-2640): opportunity + challenges #162

Open aly.codes
Open opened by aly.codes

MCP servers can now ship agent skills (SEP-2640, Final). albedo already has an MCP client and a native skills system, so it's well placed to be one of the first harnesses to connect the two. there are real design questions, mainly around trust and code execution.

not proposing an implementation, just writing down the opportunity and the friction i see. happy to help if it's wanted, and fine if it isn't.

the opportunity
  • SEP-2640 adds an io.modelcontextprotocol/skills extension. servers serve Agent Skills as skill://<path>/<file> resources, list them with skills/list, and return one skill's metadata and digests with skills/get. (spec: enumeration, retrieval)
  • server side support exists: the Python, C#, and Go SDK reference PRs, plus FastMCP (SkillsExtension / SkillCatalogProvider in 4.2.0a1). there's also a demo in github-mcp-server#3046.
  • host support is thin. the SEP lists only prototypes (gemini-cli, fast-agent, codex forks, an internal Claude Code one) (reference implementations). so there aren't many places to actually use these skills yet.
  • albedo already has most of the pieces:
    • an MCP client that does stdio and streamable HTTP, both the 2026-07-28 server/discover flow and initialize, and already lists and reads resources (robot-docs/mcp.md)
    • a progressive-disclosure skills extension with a catalog, slash commands, skills.read / skills.resources, and load tracking (robot-docs/skills.md)
    • the SEP's suggested host design is basically that: merge MCP-served skills into the existing registry, load them through the same path, and read supporting files through a resource read (hosts: end-to-end integration)
  • concrete example: i run a public atproto docs MCP server (https://atproto-docs-mcp.fastmcp.app/mcp) that serves an atproto-docs skill. today, Claude clients ignore MCP-served skills.
challenges i see
  • identity isn't name. albedo's skill catalog is keyed by frontmatter name with workspace/user/built-in scope. the SEP says an MCP skill's identity is (host-assigned server label, SKILL.md uri), that names can collide within and across servers, and that an MCP skill must never silently shadow a local one (names, skill URIs). that touches the catalog types, slash command naming, and skill_loads.
  • no implicit local execution. the SEP says MCP-served skill content must not cause host-side code execution without explicit per-skill user approval, including code-execution tool calls the model makes while acting on the skill (security implications). albedo's model is built around a trusted Python REPL, so it's an open question what "acting on an MCP skill" and that approval gate would look like here. this seems like the biggest one, and it's a design call, not a plumbing one.
  • integrity rules. hosts verify sha256 and size of every file against the listed entry, compare parsed frontmatter field by field, fetch lazily (never ahead of need), and only read files listed in the held entry (integrity and verification). if approvals are persisted, they're bound to the digest set and revoked when it changes.
  • origin-scoped reads. a skill from server A must not cause a resources/read on server B without per-call approval. servers are identified by host label, not serverInfo.name.
  • allowed-tools must be ignored for MCP skills unless the user approves it. albedo already treats it as descriptive-only, so this one may come close to free.
  • caching, if done, has to live outside every filesystem skill discovery path and keep its MCP-origin status across restarts.
  • negotiation. albedo currently declares no client capabilities. this would mean advertising the extension and reading the server's capabilities.extensions in both the initialize and _meta eras (capability declaration, per SEP-2133).
  • current overlap. a server like mine also lists skill:// files in resources/list. albedo's generic read_resource would surface them as plain resources. the SEP is explicit that such a read is not a skill load (reading).
references

🤖 issue body compiled by claude

Sign up or Sign in to add to the discussion.