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 exactly as the gate on a machine is: a banned skill, or one a Block policy covers, is refused at the tool call (its content never enters the conversation); a deprecated skill, or one a Warn policy covers, arrives with a warning; and every load (load_skill, get_skill_file) lands in your org's tamper-evident audit log — the same hash chain the CLI gate writes to. Listing skills (list_skills) isn't audited.

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.

Clients that support MCP authorization (claude.ai, ChatGPT, Codex, Cursor, VS Code and others) only need the server URL, https://skillsvault.io/api/mcp. On the first call, the client is pointed to skillsvault to sign in. You choose the organisation and allow access, and the client gets a token for that organisation, scoped to these read-only tools.

As you. Every load is recorded in the audit log under your name, and your organisation's policies apply exactly as they do on a machine.
Revocable. Connected apps are listed on your account page, and Disconnect ends access at once. Leaving an organisation ends the apps you connected to it.
Standard. OAuth 2.1 with PKCE (S256), with clients registered by Dynamic Client Registration or a Client ID Metadata Document. Metadata is at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource. Access tokens last an hour. Refresh tokens rotate, and reusing one revokes access.

Agent keys keep working everywhere, and are what the CLI and headless setups use.

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

The plugin is the quickest way in. It adds the MCP server, the skillsvault skill and the gate hook, and keeps your agent key in the system keychain:

claude plugin marketplace add skillsvault/skillsvault-skill
claude plugin install skillsvault@skillsvault

To add only the MCP server:

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>" }

Grok (xAI API)

Pass the server as a remote MCP tool, with your agent key as authorization. It works with or without a Bearer prefix:

{
  "type": "mcp",
  "server_url": "https://skillsvault.io/api/mcp",
  "server_label": "skillsvault",
  "authorization": "<agent-key>"
}

MCP Registry

skillsvault is listed in the official MCP Registry as io.skillsvault/skillsvault. Clients and gateways that read the registry can install it from there.

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. Blocked skills (banned, or covered by a Block policy) are excluded; a warned one carries its warning. Not audited.
`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 the way the gate evaluates a skill on a machine — the skill's status and your active policies, the most restrictive winning. Each load_skill and get_skill_file call is recorded; list_skills is not:

Outcome	When	`load_skill` behavior	Audit decision
Allow	Nothing against it	Content delivered	`allowed`
Warn	Deprecated, or a Warn policy matches	Content delivered with a warning naming the reason	`warned`
Block	Banned, or a Block policy matches (by skill, namespace, declared target or capability)	Refused — content never leaves the registry	`blocked`

list_skills offers only what load_skill would deliver, and get_skill_file follows the same decision as load_skill.

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.