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

[svg153]

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:

• Repository: https://github.com/svg153/github-stars-contrib-mcp-server
• Author: @svg153
• Relevant artifacts:
  • initiative / implementation sequence: initiative: expose canonical Agent Skills through the official MCP Skills extension svg153/github-stars-contrib-mcp-server#48
  • canonical catalog + manifests: feat(skills): add canonical manifest and resource catalog svg153/github-stars-contrib-mcp-server#53
  • io.modelcontextprotocol/skills implementation: feat(skills): serve canonical Agent Skills over MCP svg153/github-stars-contrib-mcp-server#54
  • security + official conformance evidence: test(skills): prove SEP-2640 conformance and security boundaries svg153/github-stars-contrib-mcp-server#55
  • same-source standalone distribution: feat(skills): add single-source standalone distribution svg153/github-stars-contrib-mcp-server#56
  • evidence model: https://github.com/svg153/github-stars-contrib-mcp-server/blob/main/docs/mcp-skills-evidence.md
  • distribution/origin policy: https://github.com/svg153/github-stars-contrib-mcp-server/blob/main/docs/skills-distribution.md

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 svg153/skills#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.