temps-mcp-setup

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 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).