What this is

The agent-facing surface. Every spoke method is exposed as an MCP tool named <slug>.<method> (e.g. job-family-agent.classify), declared from the same logic as the HTTP route.

Auth & scopes

• Header: Authorization: Bearer <key> or x-toolbox-service-key: <key>.
• Per-consumer scoped keys: TOOLBOX_MCP_KEY_<CONSUMER> (e.g. TOOLBOX_MCP_KEY_PERFORMIX) maps to a scope set in src/lib/mcp/auth.ts — an agent reaches only the tools its consumer is scoped for.
• TOOLBOX_SERVICE_KEY is recognized as legacy with full ["*"] scopes during the transition window (and otherwise means HTTP POST gates only).

Tool naming

<slug>.<method> — the slug matches the HTTP route namespace, so an agent and an engineer call the same capability by the same name across transports.

Tool catalog (generated from the registry)

One tool per live spoke method. The authoritative set is generated from src/lib/contracts/registry.ts + each spoke's contract. Examples:

• job-family-agent.classify — resolve a title/JD into the canonical Job Family × Focus × Level.
• anycomp.scenarios — generate measured compensation scenarios from leadership priorities.
• manager-effectiveness.score — Leadership Index scoring.
• segmentation-studio.* · workforce-planning.* · wage-compliance.* — HRIS-spine and comp tools.

Full generated reference

The complete tool table is generated from docs/capability-manifest.json → reference-mcp.generated.md (23 MCP tools). Regenerate with node ~/devplane/scripts/gen-product-reference.mjs ..

Smoke test

npm run mcp:smoke      # PAT-24 MCP client smoke (dev server + a TOOLBOX_MCP_KEY_* or TOOLBOX_SERVICE_KEY)

Honest scope

The full tool list + input schemas should be generated from the contracts, not hand-listed here. Scopes are enforced server-side; discovering a tool name is not authorization to call it.

See also

APIs (REST) · Getting Started · Concepts