Integrate a harness

/llms.txt is the index and /llms-full.txt includes published SKILL.md bodies. Both are bounded and both say when they left listings out; ?limit= picks a slice size (index: 100, 250, 500 or 1000; full: 25, 50, 100 or 200). The catalog holds six figures of skills, so neither document is the whole catalog, and neither pretends to be.

Every skill page advertises its Markdown variant through rel="alternate", and the Markdown response names the HTML canonical in a Link header.

POST https://skillx.sh/api/mcp speaks JSON-RPC 2.0 over the streamable-HTTP transport. The server is read-only, so it implements `initialize`, `tools/list`, and `tools/call`, and answers anything else with `method not found` rather than a stub. It does not open a server-sent event stream.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "check_compatibility",
    "arguments": { "slug": "find-skills", "target": "agentkit@1.2.0" }
  }
}

A tool failure is a successful call whose result carries isError, so the reason is readable. A listing that simply is not there comes back as found: false with a reason code, because “not in the registry” and “the call failed” are different answers.

declared is a publisher claim. verified is evidence bound to the exact artifact digest. unsupported and blocked are decisions against a requested target. unknown is the absence of a claim.

Only `declared` and `verified` mean support, and a search filter never drops an undecidable listing silently: the response carries a report of how many were evaluated, matched, and left undecided, so a short result is explained rather than mysterious. Treating `unknown` as compatible is the single most common way an integration reports support it did not verify.

Public listings return their SKILL.md content. A protected listing answers with metadata and no body, and says so — in the JSON it omits `content`, and in Markdown it prints an explicit note instead of an empty section. An empty section would read as an empty skill.

Browser pages that support the WebMCP draft API get three read tools (search, get skill, check compatibility) registered in-page. That is a progressive enhancement: everything above works without it.