Connect via MCP

skillsvault exposes your registry as a hosted MCP server at https://skillsvault.io/api/mcp. Any MCP client — Claude Code, Cursor, Codex, Gemini, or a hosted agent with no filesystem at all — connects with one config entry and can browse and load your org's approved skills in-conversation. Nothing is installed on the machine.

Unlike a plain skill catalog, delivery over MCP is governed: a banned skill is refused at the tool call (its content never enters the conversation), a deprecated skill arrives with a warning, and every request lands in your org's tamper-evident audit log — the same hash chain the CLI gate writes to.

MCP or the CLI?

MCP is the reach plane: zero-install, works in any client, content is used in-conversation only. The CLI is the enforcement plane: it installs approved skills into harness skill directories, removes banned ones, and runs the runtime gate. Use both — they share the same registry, keys, and audit trail.

Connect a client

Authentication uses an org-scoped agent key (Settings → API keys, or the Get connected widget on your dashboard). The key resolves your org — no org flag or slug needed.

Claude Code

claude mcp add --transport http skillsvault https://skillsvault.io/api/mcp \
  --header "Authorization: Bearer <agent-key>"

Cursor, Codex, Gemini, and anything else

Any client that speaks streamable HTTP takes the same JSON shape:

{
  "mcpServers": {
    "skillsvault": {
      "url": "https://skillsvault.io/api/mcp",
      "headers": { "Authorization": "Bearer <agent-key>" }
    }
  }
}

For Codex, the equivalent ~/.codex/config.toml entry:

[mcp_servers.skillsvault]
url = "https://skillsvault.io/api/mcp"
http_headers = { Authorization = "Bearer <agent-key>" }

Tool reference

Your agent calls these automatically from natural language ("load our deploy runbook skill") — listed here with arguments for completeness.

Tool	Arguments	What it does
`list_skills`	—	The org manifest: every skill with name, current version, and status. Banned skills are excluded.
`load_skill`	`name`	Full SKILL.md instructions for one skill, plus version, status, and bundled file paths. Banned → refused. Deprecated → delivered with a warning.
`get_skill_file`	`name`, `path`	One bundled file (e.g. `references/style.md`) from the skill's current version. Same policy gate as `load_skill`.

Governance semantics

Every tool call is evaluated against the skill's registry status and recorded:

Skill status	`load_skill` behavior	Audit decision
`active`	Content delivered	`allowed`
`deprecated`	Content delivered with a warning	`warned`
`banned`	Refused — content never leaves the registry	`blocked`

Audit events carry harness: "mcp", the skill name and version, and join the same per-org hash chain as CLI gate events — verifiable end to end with audit_verify_chain.

Treat loaded skills as instructions, not gospel

Skill content returned over MCP flows into your agent's context like any tool result. The registry's review and versioning gates what can arrive, and the audit log records what did — but keep org review strict: anything approved here is effectively executable process for every connected agent.

Limits

API key auth only for now — OAuth (dynamic client registration + PKCE) is on the roadmap.
Read-only: publishing still goes through skillsvault publish or the console.
No disk install over MCP: skills are used in-conversation. For on-disk installs and the runtime veto, use skillsvault pull and the gate.