MCP server

A hosted MCP server for Stacks contract monitoring: call show, when and logs from Claude Code, Codex or Cursor. Use the hosted server, or run it locally.

Hosted

Stateless: each request is signed in on its own, and nothing is kept between calls. Sign in with your browser, no key needed.

Claude Code:

claude mcp add --transport http sentinel https://api.runsentinel.app/mcp

Then run /mcp, pick sentinel and sign in. The browser opens runsentinel.app: sign in with your email link, check the app name and allow it. You can lower each area it asks for. It shows under Settings → API keys as an app; revoke it there.

Cursor, in ~/.cursor/mcp.json:

{
  "mcpServers": {
    "sentinel": { "url": "https://api.runsentinel.app/mcp" }
  }
}

For CI or a headless agent, send a key instead (Settings → API keys or sentinel keys create). It looks like sk-snt_…; a secondlayer API key won't work here.

claude mcp add --transport http sentinel https://api.runsentinel.app/mcp \
  --header "Authorization: Bearer sk-snt_…"

The endpoint is POST /mcp (Streamable HTTP). No bearer gets 401 with WWW-Authenticate: Bearer resource_metadata=…, which starts the sign-in (OAuth 2.1 with PKCE, client registration by DCR). GET and DELETE get 405. Each tool call runs through the API with that sign-in's areas, and the 120 requests a minute apply. An app's access token works only on /mcp: it lasts an hour and refreshes for 30 days.

Local

Over stdio, Node 22 or newer.

claude mcp add sentinel \
  --env SENTINEL_API_KEY=sk-snt_… \
  -- npx -y -p @secondlayer/sentinel sentinel-mcp

{
  "mcpServers": {
    "sentinel": {
      "command": "npx",
      "args": ["-y", "-p", "@secondlayer/sentinel", "sentinel-mcp"],
      "env": { "SENTINEL_API_KEY": "sk-snt_…" }
    }
  }
}

Without SENTINEL_API_KEY, the local server uses the login sentinel login saved. SENTINEL_API_URL is optional.

First run

No login yet? The server still starts. The first tool call returns sign_in_required with a link and a code (structuredContent: { status, verificationUrl, userCode, expiresAt }). Open the link and confirm the code, then call the tool again: it waits up to 60 s for the approval, saves the login and runs.

Let an agent run it

Let an agent run the reads without asking. Everything else (when, every, at, off, destinations add, remove …) stays a prompt, so a person sees the full line before anything is added, rerouted or stopped. The read verbs refuse --yes and every write flag, so appending flags to an allowed prefix can't widen it. Don't add a blanket sentinel * rule, and don't list keys.

Claude Code, in .claude/settings.json. An ask rule beats an allow rule, so there is none: Claude Code asks for any command that isn't allowed. The mcp__sentinel__ rules assume the server is named sentinel.

{
  "permissions": {
    "allow": [
      "Bash(sentinel whoami *)",
      "Bash(sentinel status *)",
      "Bash(sentinel alerts *)",
      "Bash(sentinel ask *)",
      "Bash(sentinel contracts *)",
      "Bash(sentinel describe *)",
      "Bash(sentinel list *)",
      "Bash(sentinel show *)",
      "Bash(sentinel logs *)",
      "Bash(sentinel destinations *)",
      "mcp__sentinel__whoami",
      "mcp__sentinel__status",
      "mcp__sentinel__alerts",
      "mcp__sentinel__ask",
      "mcp__sentinel__contracts",
      "mcp__sentinel__describe",
      "mcp__sentinel__list",
      "mcp__sentinel__show",
      "mcp__sentinel__logs",
      "mcp__sentinel__destinations"
    ]
  }
}

OpenCode, in opencode.json. The last matching rule wins, so the catch-all comes first.

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "sentinel *": "ask",
      "sentinel whoami": "allow",
      "sentinel whoami *": "allow",
      "sentinel status": "allow",
      "sentinel status *": "allow",
      "sentinel alerts": "allow",
      "sentinel alerts *": "allow",
      "sentinel ask": "allow",
      "sentinel ask *": "allow",
      "sentinel contracts": "allow",
      "sentinel contracts *": "allow",
      "sentinel describe": "allow",
      "sentinel describe *": "allow",
      "sentinel list": "allow",
      "sentinel list *": "allow",
      "sentinel show": "allow",
      "sentinel show *": "allow",
      "sentinel logs": "allow",
      "sentinel logs *": "allow",
      "sentinel destinations": "allow",
      "sentinel destinations *": "allow"
    }
  }
}

The agent skill (npx skills add https://runsentinel.app) teaches the same rules; see Quickstart.

Confirm before it happens

The tools are the CLI's verbs, one each (destinations add is destinations_add), and they answer the same way: a write returns { done, willDo, effect, next }, a read its data and next. next is the next command, sentinel <verb> …; as a call, its verb is the tool.

• Read tools never write.
• Write tools act at once, and dry_run: true previews any of them. when, every and at answer a cost (a check, a contract over your tier's count) with done: false until confirm: true.
• Confirm tools (off, remove, destinations_remove, backtest, test_alert) return a preview (done: false) and change nothing until you call them again with confirm: true.

Tools

A target is a contract (its id, or its name on your account), or an id: a watch w_…, a schedule sch_…, a check run chk_…, an alert alr_….

Read

Write: at once, dry_run previews

Confirm: previews until confirm

Limits

A key without the area a tool needs gets the API's 403 This key needs Monitoring: write. back from the tool. Sign-in, billing and API keys stay on the account page (/account); everything else, a tool does.