modelcontextprotocol / modelcontextprotocol/ext-skills

Experimental finding: Stars MCP server passes official SEP-2640 server conformance scenarios with single-source skill delivery

Open
#144 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
MDX
Stars
655
Forks
58
Avg merge
4d 14h
Merged PRs (30d)
9

Description

GitHub Stars Contributions MCP Server

Scope: this reports server-side protocol conformance and implementation findings only. Native host activation, automatic skill selection, and model adherence were not tested and are not claimed here.

Date: 2026-09-15

Implementation:

Approach tested:

Provider-owned Agent Skills colocated with the MCP server, exposed through the official io.modelcontextprotocol/skills extension (skills/list, skills/get) and lazy standard MCP Resources. The same canonical skills/* tree is also usable as a standalone Agent Plugin fallback; there is no second editable skill copy.

Setup:

  • Clients tested: official MCP Python SDK 2.2.0 in-memory Client; official modelcontextprotocol/conformance server runner pinned to commit 7169291ec0b68eb370fddcd9947313ab0d5e4156
  • Models tested: Not tested for this finding
  • Configuration notes: Python 3.12; real Stars server over Streamable HTTP for conformance; four canonical skills; static manifests; optional directoryRead deliberately not advertised

What was tested:

  • extension discovery;
  • deterministic/paginated skills/list;
  • direct skills/get without requiring a prior list call;
  • lazy resources/read of exact skill files;
  • SHA-256 + byte-size equality between manifests and returned bytes;
  • traversal / encoded traversal / symlink escape / malformed frontmatter / invalid identity / unknown URI / stale-manifest handling;
  • separation of Agent Skill metadata (allowed-tools) from server-side authorization;
  • official SEP-2640 server scenarios:
    • sep-2640-skills-enumeration;
    • sep-2640-skills-manifest;
    • sep-2640-skills-directory (optional-capability boundary);
  • standalone compatibility from the same root skills/* tree.

Results:

  • What worked: The official MCP Python SDK 2.x Extension, MethodBinding, ResourceBinding, FunctionResource, and normal Resources primitives were sufficient; no protocol fork or parallel FastMCP layer was necessary. Static manifest + lazy read passed the official server conformance scenarios above. The server can fail closed on resource drift and unsafe/unmanifested URIs. The same canonical root skill tree can serve MCP runtime delivery and a portable Agent Plugin fallback.
  • What didn't: No production model-facing host activation is demonstrated by this experiment. Passing SDK round-trips and official server conformance does not show that a host will automatically expose/select/load the served skill for the model.
  • What was surprising: directoryRead was unnecessary for the static repository-backed model; complete manifests plus normal Resources were sufficient for the tested contract. Also, the implementation exercise reinforced that advertised resource digests are snapshot-consistency evidence, not independent publisher attestation when the same server provides both digest and bytes.

Requirements or design questions addressed:

  • one canonical skill source with MCP and standalone delivery;
  • provider-side progressive disclosure and lazy loading;
  • resource integrity / path safety;
  • optional directory capability boundary;
  • distinction between protocol conformance and model-facing host activation;
  • runtime MCP delivery vs build-time dependency/catalog governance;
  • duplicate standalone/MCP origin handling.

Evidence and reproduction:

The repository CI includes an official-conformance workflow that starts the real server with Stars mutation tools disabled and executes the three SEP-2640 server scenarios above. PR #55 contains the implementation/evidence change and all scenario jobs passed. The same repository also has official-SDK client tests and negative security/integrity tests, so protocol unit evidence and conformance evidence are separate.

Limitations:

  • No claim of automatic model-context activation/adherence in Copilot, Claude, Codex, VS Code, or another production host.
  • The finding is strongest for static repository/package-backed skills; dynamic/multi-tenant skill generation may justify different manifest/directory behavior.
  • SHA-256/size are integrity/snapshot checks, not an independent trust/identity mechanism.
  • Client-side cross-origin collision handling remains host-dependent; the local policy is to preserve origin, never concatenate instruction bodies silently, and surface a conflict when same-name contents differ.

Sources and attribution:

Implementation and evidence by @svg153, derived from the public repository/PRs linked above. The architecture feedback has also been captured in https://github.com/svg153/skills/pull/68.


I am filing this as a reproducible experimental finding first because experimental-findings.md notes that current discussion is moving through WG channels. If maintainers prefer a documentation PR using docs/findings-template.md, I can adapt this into the repo's preferred current location.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review experimental-findings.md and docs/findings-template.md to determine where this reproducible finding belongs. Use the linked evidence, conformance results, and stated limitations to adapt the report if the repository's current format is appropriate; done means the finding is documented in the preferred location or its placement is clarified.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.