/temps-mcp-setup

name: temps-mcp-setup
description: |
  Configure Temps as an MCP (Model Context Protocol) server so AI assistants can interact with a Temps instance directly -- listing/inspecting projects and deployments, and (when write mode is enabled) triggering deployments with human confirmation. Use when the user wants to: (1) Set up the Temps MCP server, (2) Connect Claude Code/Desktop, Codex, Cursor, VS Code, Windsurf, or Zed to Temps, (3) Add Temps tools to an AI assistant, (4) Test the MCP wizard locally, (5) Manage multiple Temps MCP connections (dev, staging, prod, or several local dev slots) side by side. Triggers: "temps mcp", "configure temps tools", "add temps to claude", "temps ai assistant", "mcp server setup", "mcp add", "test the mcp wizard".

Temps MCP Setup

Temps serves MCP (Model Context Protocol) directly from the `temps` binary itself (ADR-039, `crates/temps-mcp-server`) -- there is no separate package to install or keep up to date. The MCP endpoint calls the same service layer as the REST API, so it cannot drift from it the way the old standalone `@temps-sdk/mcp` npm package did (removed in PR #355 for exactly that reason -- do not reinstall it or point a client at it).

Installer wizard lives in `apps/temps-cli/src/commands/mcp/` (`bunx @temps-sdk/cli mcp add|remove|status`).

1. Enable the MCP server (operator, one-time per instance)

Off by default (`AppSettings.mcp_server.enabled = false`), so a fresh install never exposes it unconfigured. Turn it on as an admin:

bunx @temps-sdk/cli mcp enable

If you're not logged in yet, `mcp enable` offers to run the device-flow login inline (see [Auth model, precisely](#2-configure-your-ai-client-per-user-per-client) below) -- no separate `temps login` step required first.

`mcp enable` does the same GET-modify-PUT round-trip against `/api/settings` the handler requires (it takes the **full** `AppSettings` object, not a partial patch), merging onto whatever is already fetched so it can never clobber another admin's settings. `mcp disable` reverses it.

Verify it took effect, or check status any time without re-running enable:

bunx @temps-sdk/cli mcp status
# "This instance: <check> enabled (http://localhost:8080)" or "<bullet> disabled (...)"

Or probe the endpoint directly (no auth needed for this one):

curl -s http://localhost:8080/mcp/tools
# {"groups":[{"key":"deployments","label":"Deployments & Projects"}, ...]}
# A 404 here means the flag is still off (or this instance predates MCP support).

2. Configure your AI client (per user, per client)

bunx @temps-sdk/cli mcp add <client>

`<client>` is one of: `claude-code`, `claude-desktop`, `codex`, `cursor`, `vscode`, `windsurf`, `zed`.

**Auth model, precisely:** `mcp add`/`mcp enable`/`mcp disable` need you logged into the CLI so the wizard can mint an API key on your behalf -- that login has nothing to do with MCP itself. If you're not already logged in, these commands detect that and offer to run the device-authorization flow right there (prompts "Log in now?", then "Temps server URL", defaulting to your current config) rather than erroring out and making you run `temps login` as a separate step first. Under the hood it's the same flow `temps login` uses (`/auth/cli/device/start` + `/auth/cli/device/poll`, server-authoritative polling, no code to type, browser approval). In `--yes` (non-interactive) mode this inline offer is skipped -- pass `--api-key` or ensure a context is already logged in. What actually gets written into the AI client's config either way is a plain, long-lived `Authorization: Bearer <api-key>` header -- the same static-bearer-token pattern PostHog's own MCP wizard uses, and one of the two auth patterns the MCP HTTP transport spec supports (the other being full OAuth 2.1 + dynamic client registration, which most of these 7 clients don't yet implement for remote MCP servers anyway).

The wizard will: 1. Probe `/mcp/tools` to confirm the instance has MCP enabled (see step 1). If it 404s, it tells you so and stops -- it will not silently write a broken config. 2. Ask which tool groups to enable (default: all). 3. Ask whether to enable write tools (default: **no** -- read-only). Write tools still require human confirmation per call even when enabled (see below). 4. Offer to create a dedicated, scoped API key for MCP access, recommended over reusing a broader existing credential. The new key's role is `role_type: 'reader'` when write mode is off, `'user'` when it's on (the `user` role carries `DeploymentsWrite`; `reader` does not). 5. Write the client's config file (or, for Claude Code/Codex, shell out to their own `claude mcp add` / `codex mcp add` so their config format is never hand-maintained here).

Other subcommands:

bunx @temps-sdk/cli mcp status         # which clients on this machine have Temps configured
bunx @temps-sdk/cli mcp remove <client>

Restart the AI client after running `mcp add` -- most clients only read MCP config at startup.

3. Testing the wizard locally, end-to-end

Bring up a local instance with the `start-temps` skill first (or reuse one you already have running), noting its **slot** -- every non-zero slot has its own ports, database, and login, so treat the printed `web`/`api` URLs as this instance's identity for the rest of this section.

Fastest path to a working test without the interactive prompts: `mcp add --yes` with an explicit `--api-key`, pointed at the slot's API URL via `TEMPS_API_URL` (or `--target-context`, if you've already run `temps login` against that instance and saved a context).

# One-time per slot: enable the flag (step 1) and mint a throwaway admin key
# (or use the wizard's own key-creation step interactively instead).

TEMPS_API_URL=http://localhost:<8080+slot*10> bunx @temps-sdk/cli mcp add claude-code \
  --api-key <key> --yes

Then drive the protocol directly with `curl` -- this is the fastest way