Skip to content
stack
Get started
Integrations

MCP integration

Stack ships as an MCP server. Any LLM editor that speaks MCP — Claude Code, Cursor, Windsurf, Zed — can drive Stack directly from a chat.

Two directions of MCP

Stack is both a producer and a consumer of MCP:

  • Producer: Stack itself is an MCP server (@ashlr/stack-mcp). It exposes 17 tools so an LLM editor can call stack add, stack doctor, etc. without a terminal.
  • Consumer: When you stack add a service that has its own MCP server (Supabase, PostHog, Sentry, GitHub, Linear), Stack merges that server's config into your project's .mcp.json so the same editor can reach into the service.

Installing Stack as an MCP server

The simplest path is the Claude Code plugin, which also registers slash commands: 

claude plugin install ashlrai/ashlr-stack

Or wire it by hand. The server is a stdio MCP binary; add it to your editor's MCP config:

Claude Code (or any global .mcp.json)

{
  "mcpServers": {
    "ashlr-stack": {
      "command": "npx",
      "args": ["-y", "@ashlr/stack-mcp"],
      "env": {}
    }
  }
}

Cursor

Cursor reads the same .mcp.json format. Drop the snippet above into ~/.cursor/mcp.json or your project-level one.

Windsurf / Zed

Both editors speak MCP via stdio; use the same command/args shape in their config.

Already have stack on PATH? You can skip the npx shim and just use "command": "stack-mcp". Stack resolves the CLI path via $STACK_BIN if you need to point at a non-standard install.

Tools — 17 total

Every tool below maps 1:1 to a CLI command. The server spawns stack <args> with NO_COLOR=1 and CI=1 so output is clean for LLM consumption, then returns stdout (and stderr on errors) as text content.

stack_init stack init --noInteractive [--template <name>] [--force]

Scaffold a new .stack.toml in the current directory.

Input Type Description
template string Optional starter template name.
force boolean Overwrite an existing .stack.toml.
stack_import stack import [--from <path>] [--dryRun]

Import an existing .env file into Phantom + .stack.toml.

Input Type Description
from string Path to the .env file (default: .env).
dryRun boolean Preview without writing.
stack_scan stack scan [--path <dir>] [--confidence low|medium|high]

Detect providers this repo uses by reading package.json / requirements.txt / config files.

Input Type Description
path string Directory to scan (default: cwd).
confidence string Minimum confidence: low, medium, or high (default: medium).
stack_add stack add <service> [--use <id>]

Provision a service and wire its secrets + MCP entry.

Input Type Description
service req string Service name (e.g. supabase, neon, vercel).
use string Existing resource id to attach to.
stack_remove stack remove <service> [--keepRemote]

Remove a service from the stack (vault entries and MCP config).

Input Type Description
service req string Service name.
keepRemote boolean Leave the provider-side resource untouched.
stack_list stack list

List services configured in this stack.

No inputs.
stack_info stack info <service>

Deep-dive on a single service: resource, region, auth, secrets, MCP wiring, health.

Input Type Description
service req string Service name.
stack_status stack status

Show Phantom + services + config at a glance.

No inputs.
stack_env_show stack env show

Show which declared secrets are present in the Phantom vault (masked).

No inputs.
stack_env_diff stack env diff

Report which declared secrets are missing from the Phantom vault.

No inputs.
stack_doctor stack doctor [--fix] [--all] [--json]

Verify every service is reachable and credentials are valid.

Input Type Description
fix boolean Attempt auto-remediation.
all boolean Run across every registered project.
json boolean Machine-readable JSON output.
stack_sync stack sync --platform <name>

Push secrets to a deployment platform (via phantom sync).

Input Type Description
platform req string One of: vercel, railway, fly.
stack_providers stack providers

List every curated provider Stack can wire up (grouped by category).

No inputs.
stack_projects_list stack projects list

List every Stack-enabled project on this machine.

No inputs.
stack_deps stack deps

Show the service dependency graph for the current stack.

No inputs.
stack_templates_list stack templates list

List available starter stack templates.

No inputs.
stack_upgrade stack upgrade

Check npm for a newer @ashlr/stack release.

No inputs.

Resources

Stack's MCP server also exposes three read-only resources so the editor can inspect the current project without a tool call:

stack://current/.stack.toml application/toml
.stack.toml (this project)
Committed shape of the current project's stack.
stack://current/.stack.local.toml application/toml
.stack.local.toml (local instance)
Local instance data (resource ids, project_id). Gitignored.
stack://current/.mcp.json application/json
.mcp.json (MCP wiring)
Currently-wired MCP servers.

Provider-side MCP servers

Several providers register their own MCP server when you stack add them. The entry is merged into your project's .mcp.json, so the same Claude / Cursor session can talk to the service directly:

Provider MCP transport What it wires
supabase stdio (npx) @supabase/mcp-server-supabase pinned to your new project ref, with SUPABASE_ACCESS_TOKEN resolved via Phantom.
posthog sse mcp.posthog.com/sse with the POSTHOG_PERSONAL_API_KEY piped through Phantom's bearer header.
sentry stdio (npx) @sentry/mcp-server with SENTRY_AUTH_TOKEN via Phantom and SENTRY_HOST=https://sentry.io.
github stdio (npx) @modelcontextprotocol/server-github with GITHUB_PERSONAL_ACCESS_TOKEN via Phantom.
linear stdio (npx) mcp-linear with LINEAR_API_KEY via Phantom.
Secrets stay phantom-gated. Every env var for these MCP servers is resolved via $(phantom reveal …) at spawn time. The agent sees the slot name in .mcp.json, never the real value.

Plugin slash commands

The Claude Code plugin adds a handful of slash commands that wrap the most common MCP tool calls with better defaults and prompts:

  • /stack:add — provision a service from chat, with an interactive picker.
  • /stack:doctor — run healthchecks inline, with structured diffs.
  • /stack:open — open a service's dashboard from the chat.
  • /stack:init, /stack:status, /stack:deps — thin wrappers around the obvious commands.

Example chat

Here's a real interaction once you have both Stack's MCP server and a provider-side MCP server wired: 

You > Can you add Supabase to this project?

Claude > I'll use stack_add to provision a new Supabase project.
         (calls stack_add with service: "supabase")
         ● supabase (abcdefghijklmnop) · 3 secrets · mcp wired
         Done. The new supabase MCP server is now available — want me
         to create your first table?

You > Yes, users with email + created_at

Claude > (calls the supabase MCP server's execute_sql tool)
         Created public.users with email (text, unique) and
         created_at (timestamptz default now()).