Connect your agent

Quartermaster is a standard MCP server (Streamable HTTP), so any tool that speaks MCP can use it. Connecting takes two steps, whatever you run:

Register the MCP endpoint in your tool.
Teach the agent to route through it — with the router skill (open Agent Skills format) where your tool supports skills, or a one-paragraph rules snippet where it doesn’t.

First, pick where your registry runs — every snippet on this page rewrites itself to match (copy buttons included):

Local / Docker Cloud hub (Worker)

MCP endpoint: http://localhost:8765/mcp

No token needed on loopback unless you set AUTH_TOKEN.

A cloud hub always requires auth — send Authorization: Bearer <token> with every call (--header in Claude Code, a headers map in the JSON configs below).

The rest is common to every client: the transport is Streamable HTTP, and auth is a plain Authorization: Bearer <token> header — optional on loopback, required whenever the server is bound non-loopback or running as a cloud hub.

Register the MCP server

# user scope = available in all your projects
claude mcp add --transport http quartermaster http://localhost:8765/mcp --scope user
claude mcp list                                   # should show quartermaster

If you set an AUTH_TOKEN, add --header "Authorization: Bearer <token>" to the add command.

Add to ~/.codex/config.toml:

[mcp_servers.quartermaster]
url = "http://localhost:8765/mcp"

If your Codex build only supports stdio MCP servers, use the mcp-remote bridge instead.

Add to ~/.gemini/settings.json (or a project’s .gemini/settings.json):

{
  "mcpServers": {
    "quartermaster": {
      "httpUrl": "http://localhost:8765/mcp",
      "headers": { "Authorization": "Bearer <token, if set>" }
    }
  }
}

Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json in a project:

{
  "mcpServers": {
    "quartermaster": { "url": "http://localhost:8765/mcp" }
  }
}

In the MCP Servers panel choose Remote Servers → Add, or edit cline_mcp_settings.json:

{
  "mcpServers": {
    "quartermaster": {
      "url": "http://localhost:8765/mcp",
      "type": "streamableHttp"
    }
  }
}

Pi has no built-in MCP client, but it loads Agent Skills natively — the router skill works as-is:

cp -r skills/quartermaster-router ~/.pi/agent/skills/

The skill can then reach the registry through Quartermaster’s JSON API (curl http://localhost:8765/api/...), or you can bridge the MCP tools with a Pi extension.

Qwen Code uses Gemini-CLI-compatible settings — add to ~/.qwen/settings.json:

{
  "mcpServers": {
    "quartermaster": { "httpUrl": "http://localhost:8765/mcp" }
  }
}

Anything else (stdio-only clients)

Most other harnesses (Grok, DeepSeek, Hermes, …) accept the same generic mcpServers map in their settings file — a url entry pointing at the endpoint above. For clients that only launch stdio MCP servers, bridge with mcp-remote:

{
  "mcpServers": {
    "quartermaster": {
      "command": "npx",
      "args": ["mcp-remote", "http://localhost:8765/mcp"]
    }
  }
}

(Add "--header", "Authorization: Bearer <token>" to args if you set one.)

Install the router skill

The resident router skill teaches agents to reach for the registry instead of guessing at capabilities. It ships in the open Agent Skills format — a folder with a SKILL.md (YAML frontmatter + instructions) — so the same folder works in every harness that has adopted the standard. Copy it into your tool’s skills directory:

cp -r skills/quartermaster-router ~/.claude/skills/    # Claude Code
cp -r skills/quartermaster-router ~/.codex/skills/     # Codex
cp -r skills/quartermaster-router ~/.grok/skills/      # Grok
cp -r skills/quartermaster-router ~/.pi/agent/skills/  # Pi
# any other Agent Skills-compatible harness: its skills/ directory

The skill is deliberately narrow — it steers the agent to the read/search tools (search_capability, fetch_capability, list_capabilities, census, reindex) and instructs it: don’t guess or load skills by name — route through the Quartermaster MCP first.

Tools without skill support

If your harness doesn’t load Agent Skills, put the routing instruction in its rules file instead — AGENTS.md, GEMINI.md, QWEN.md, GROK.md, .cursorrules, or .clinerules:

Before improvising a procedure or loading a skill/rule by name, query the
`quartermaster` MCP server: `search_capability(<task description>)`, then
`fetch_capability(id)` on the best match. Prefer a returned capability over
inventing an ad-hoc approach; only fall back when nothing relevant matches.

And Quartermaster can dogfood this: once one tool is connected, ask it to convert_capability the router skill for another tool and install it with preview_hydration → apply_hydration — see Conversion & compatibility and Hydration.

Try it

In a session, confirm the tools are connected (/mcp in Claude Code, Codex, Gemini CLI, and Qwen Code; the MCP panel in Cursor/Cline), then ask something like:

“Is there a skill for pulling tables out of a PDF?”

The agent should call search_capability, then fetch_capability on the best match — one capability served on demand, instead of everything preloaded into every session.