Gateway — REST + MCP overview

The gateway is the one process every agent, dashboard, and CLI command talks to. It's a local daemon (http://localhost:3100) that exposes the same capabilities two ways: an MCP endpoint for agents, and an HTTP REST API for the dashboard, CLI, and your own scripts.

This page is the narrative map. For the exhaustive, generated-from-source detail, use:

MCP tool reference — every tool, its

parameters, generated straight from TOOL_DEFINITIONS in the gateway source.

API reference — interactive Redoc explorer over the

full OpenAPI spec, generated from the same route table the server enforces.

Two doors, one gateway

	MCP endpoint	REST API
URL	`http://localhost:3100/mcp`	`http://localhost:3100/api/*`
Who calls it	MCP-capable agents (Claude Code, Cursor, Windsurf, Codex CLI, Gemini CLI, opencode)	Dashboard, `myai` CLI, your own scripts/webhooks
Shape	JSON-RPC over the MCP `initialize` / `tools/call` protocol	Plain HTTP + JSON, documented as OpenAPI 3.0
Typical calls	`context_boot`, `brain_delta`, `memory_search`, `state_read`, `tasks_list`	`/api/tasks`, `/api/schedules`, `/api/budgets/*`, `/api/agents`, `/api/skills`

Both doors are backed by the same core: session manager, task queue, memory store, and budget tracker. A tool an agent calls over MCP and the equivalent REST route hit the same code path — there's no drift between "what the agent can do" and "what the dashboard can do."

Connecting an agent

myai connect-agent          # writes MCP config for a supported agent
myai plug claude             # same idea, framed as the "plug in" flow
myai plug proof              # live continuity round-trip with no agent installed

connect-agent writes the gateway's MCP URL into the agent's own config file (e.g. Claude Code's .mcp.json). From the next session, the MCP initialize handshake carries an auto-boot bundle and a context_boot tool call returns operator context — the agent knows who it's working with before it reads a single file.

Auth model

Loopback trust: requests from 127.0.0.1/::1 are trusted as the local

operator by default — no token needed for a single-machine setup.

GATEWAY_LOCAL_TOKEN: a shared-secret bearer token that grants the same

local-operator trust from a non-loopback caller (e.g. a container on the same Docker network). Set once in AI/.env or selfhost/.env; send as Authorization: Bearer <token>.

Session JWT: the dashboard and multi-tenant deployments use a signed JWT

(cookie myai_token, or Authorization: Bearer <jwt>) carrying the caller's tenant + role for RBAC-gated routes.

API keys: long-lived keys via x-api-key, for scripts and webhooks that

shouldn't hold a session.

See the self-host guide for the env vars that control auth, and SECURITY.md in the repo root for the full threat model.

What's on the other side

A rough map of the tool/route surface (see the two reference pages for the complete, current list):

Continuity — context_boot, brain_delta, brain_commit, brain_merge,

memory_search, recall_session, state_read

Task queue / runner — tasks_list, tasks_update, /api/tasks,

/api/schedules

Budgets — /api/budgets/status, /api/budgets/breakdown,

/api/usage/summary (operator-token gated)

Fleet — /api/agents, /api/skills, repo directory + status tools
Billing / licensing — /api/gift-codes, /api/license/status

(offline-verified, no phone-home)

Webhooks — /api/webhooks (create/update/delete/replay deliveries)

Health + status

curl http://localhost:3100/health          # liveness
curl http://localhost:3100/health/deep     # dependency checks (mongo, etc.)
myai status                                # stack health + queue counts (--json)

Next: the MCP tool reference for exact call signatures, or the self-host guide to run the gateway on your own infrastructure.