docs: add skills-extension-candidates and client-mcp-support trackers (#92)

* docs: add skills-extension-candidates tracker

Scaffold a candidates list for MCP servers, dev tools, SDKs, and
skills repositories that could adopt SEP-2640. Initial entries:
FastMCP 3.0 Skills, chrome-devtools-mcp, hf-mcp-server, Hugging Face
skills library, github-mcp-server (PR #2428 demo), Azure Skills Plugin.

Cross-link from related-work.md and add a row to the README docs
table.

* docs: add Issue/PR tracker column to candidates table

* docs: add client-mcp-support survey alongside candidates tracker

* docs: link Azure MCP Server source in candidates table

* docs: remove gemini-cli from client MCP support survey

* docs: verify hermes-agent, switch source refs to main-branch links, refresh takeaways

- Promote hermes-agent from first-pass to verified; note its per-server tool
  pattern (`mcp_{server}_read_resource` + `mcp_{server}_list_resources`) and
  confirm end-user docs exist
- Drop stale line numbers throughout; convert path refs to GitHub source-file
  links on `main` (commit-pinned URLs decayed once files moved)
- Goose: PR #8989 has landed, so describe current `(extension_name, uri)`
  required signature and drop the now-closed issue/PR tracking
- Takeaways: collapse to three implementation patterns (Goose now fits the
  `(server, uri)` bucket), fix open-source count to fourteen, drop the
  smolagents name-drop (not in survey), add strands-agents alongside mastra
  for the internal-SDK-only pattern, and reframe the signature recommendation
  around server-resolution reliability rather than URI portability

* docs: verify remaining first-pass clients, flip cline/Roo-Code to Yes

Verified adk-python, agent-framework, crewAI, mastra, cline, Roo-Code
against local source clones. Two corrections to prior state:

- cline and Roo-Code both expose access_mcp_resource(server, uri) as a
  model-facing tool via McpHub.readResource. Flipped from No to Yes.
- adk-python's load_mcp_resource takes resource_names: array[string] in
  a single call (not two-shot); opt-in via use_mcp_resources flag.

Headline count updated from six to eight of fourteen open-source clients
satisfying #2527. Cross-cutting observations and takeaways adjusted for
the new (server, uri) family members and the four-pattern signature
breakdown. Trust-model list extended.

* docs: add Figma and Adobe MCP as SEP-2640 testing candidates

* docs: update FastMCP 3.0 Skills entry with detailed notes on SEP-2640 compliance

* docs: drop unconfirmed Cursor SEP-2640 entry, track latest SEP-2640 wire-contract PRs

Remove the Cursor row + deep dive (reported WIP never confirmed). Add the
in-flight PRs realigning to the 2026-06-05/06-09 SEP-2640 schema (frontmatter +
archives[] index, resources/directory/read): hf-mcp-server#174, fast-agent#825,
huggingface/skills#172.

* docs: add Slack (interested) and Bloomberg (internal use) as SEP-2640 candidates

* docs: remove archived Roo-Code from client survey, update strands repo to harness-sdk

* docs: re-verify SEP-2640 implementations against current upstream main

Both reference implementations have migrated to the July 2026 v1 shape,
verified against fresh clones rather than the prior June commit pins:

- hf-mcp-server (d794b10, v0.4.6): skills/list + skills/get, per-file
  {uri,digest} resources manifest, directoryRead:true, no index.json or
  archives. Migrated in #219 (merged 2026-08-03). Also records the
  snapshot/TTL model and HTTP-transport-only constraint.
- fast-agent (79b903c, 0.10.1): pins SEP-2640 revision d7490ec, treats
  legacy index.json skill-md/archive entries as unsupported. Requires
  --prerelease=allow (pins fastmcp-slim 4.0.0b1), per @evalstate.

Corrects the earlier note claiming implementations lagged the SEP: the
#174/#825/#172 round merged 2026-06-19 and was never in flight, and a
second realignment followed the v1 rework.

Also fixes drift found while re-checking fast-agent's resource tool:
smart_agent.py is gone (now core/harness_tools.py), get_resource is
opt-in via harness_tools (default False, was unconditional), and
server_name is now optional - the one surveyed client where the model
may omit server identity.

Runtime skill loading is still unshipped; #816 remains open.

🦉 Generated with [Claude Code](https://claude.com/claude-code)

* docs: track SEP revision 0eb05fe and add mcpkit to the candidates tracker

The SEP moved from d7490ec to 0eb05fe (2026-08-05). The delta is
editorial for the wire contract -- skills/list, skills/get, and the
per-file resources manifest are unchanged -- so d7490ec-pinned
implementations stay compatible. Records what it does change: a soft
reg-name constraint on the first skill-path segment, the skill root URI
fixed as skill://<skill-path> with no trailing slash, whether skills/get
carries ttlMs/cacheScope reopened, and normative host obligations in the
security section.

Adds mcpkit (panyam/mcpkit, Go, v0.3.0) from #118 as a candidate. It
implements the pre-v1 index.json catalog shape with per-file digests, so
the ecosystem is now split across draft revisions rather than uniformly
caught up.

🦉 Generated with [Claude Code](https://claude.com/claude-code)

* docs: refine mcpkit entry — deliberate tracking, partial v1 migration

Checked mcpkit's issues and PRs rather than inferring alignment from
code shape. Its lag is a tracked decision, not drift:

- #1185 (merged 2026-08-04) implements origin-tagging and per-origin
  resolve citing SEP L179/L183/L185 -- the host obligations 0eb05fe made
  normative -- so it is already on v1 for the security section. #1187
  adds a SEP-2640 security/conformance harness as a WG demo.
- #780 is an explicit index-schema tracking issue that has absorbed the
  archives removal and the resources:[{uri,digest}] direction but waits
  on WG confirmation; its conformance fork pins provenance at 556154c.
- The carrier change is still unbooked: nothing references skills/list
  or skills/get.
- Archives are kept as a non-spec extended surface rather than deleted,
  unlike fast-agent -- a counter-case for whether deferring a feature
  removes it from the ecosystem.

Sharpens the callout accordingly: the draft split runs within an
implementation, not only between them, so "which draft does X
implement" often has no single answer.

🦉 Generated with [Claude Code](https://claude.com/claude-code)
This commit is contained in:
Ola Hungerford 2026-08-28 09:49:18 -07:00 • committed by GitHub
commit c1fa4f315e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -41,6 +41,8 @@ See [problem-statement.md](docs/problem-statement.md) for full details.
| [Experimental Findings](docs/experimental-findings.md) | Results from implementations and testing |
| [Related Work](docs/related-work.md) | SEPs, implementations, and external resources |
| [Threat Model](docs/threat-model.md) | Threat model for skills served over MCP (SEP-2640), with delivery-model recommendations and an archive appendix |
| [Skills Extension Candidates](docs/skills-extension-candidates.md) | MCP servers, dev tools, SDKs, and skills repositories that are candidates for adopting the skills extension |
| [Client MCP Support](docs/client-mcp-support.md) | Survey of model-facing MCP resource loading and SEP-2640 support across open-source clients |
| [Decision Log](docs/decisions.md) | Record of key decisions with context and rationale |
| [Rationale](docs/rationale.md) | Design rationale for SEP-2640's Resources-based skills extension |