MCP

Stella Loop ships a Model Context Protocol server so MCP-speaking agents — Claude Code and others — can drive the product as native tools. The server is generated from the same capability map as the API and CLI, so its tool set cannot drift from what the product can actually do.

Running the server

The MCP server is part of the CLI:

stella mcp serve                          # stdio (the common case)
stella mcp serve --transport http --port 3333   # streamable HTTP at /mcp

A typical client configuration:

{
  "mcpServers": {
    "stella": {
      "command": "stella",
      "args": ["mcp", "serve"],
      "env": { "STELLA_API_KEY": "slk_…", "STELLA_PROJECT": "ATLAS" }
    }
  }
}

The server can start before credentials exist — a tool call without a key returns a structured error naming the fix, which suits ephemeral agents that receive their key after boot. Over HTTP, each request gets a fresh, stateless server instance, so multiple coding agents can share one endpoint without leaking state between them.

The tools

Tools are named stella_<group>_<verb> — stella_work_list, stella_task_claim, stella_context_show, stella_signal_capture, stella_proposal_promote, and so on across the full surface: signals, North Star, intents, analysis, the pool, epics and tasks, specs, review, the loop engine, notifications, repositories, and search.

Each tool carries annotations derived from its scope and method — read-only, destructive, idempotent — so agent frameworks can apply their own confirmation policies sensibly. Inputs and outputs follow the same schemas as the API envelope.

The same rules apply

MCP tools hit the same /api/v1 endpoints with the same key, so scopes, project grants, rate limits, idempotency, and checkpoint gates all behave identically. An MCP agent promoting a proposal still passes epic.promote; a claim race still loses cleanly with a structured conflict.

If a capability seems missing from your client’s tool list, update the CLI — the tool set versions with it.