Skip to main content
Glama
simplisafe-mcp

simplisafe-mcp

by chrischall

simplisafe-mcp

MCP server for SimpliSafe home security. Check whether the system is armed, review sensors and events, arm/disarm, and control smart locks — from Claude.

This server can disarm a home alarm and unlock doors. Every tool that changes physical state, plus the tool that reads alarm PINs, asks you to confirm first — nothing is sent until you do, and you see a preview of exactly what would happen (see Confirmations). Install it only where you'd be comfortable with that capability.

Developed and maintained by AI (Claude Code).

What you get

Tool

simplisafe_list_systems

Systems on the account with current alarm state

simplisafe_get_system

One system's state, connectivity, base-station messages

simplisafe_list_sensors

Sensors with battery / offline / triggered status, filterable

simplisafe_list_locks

Smart locks with locked / unlocked / jammed state

simplisafe_get_events

Recent base-station events (arm, disarm, opens, alarms); view: "brief" gives one line per event

simplisafe_get_settings

Entry/exit delays, volumes, base-station health

simplisafe_get_pins

Alarm PINs — cleartext, asks you to confirm first

simplisafe_set_alarm_state

Arm home / arm away / disarm — asks you to confirm first

simplisafe_set_lock_state

Lock / unlock a door — asks you to confirm first

simplisafe_healthcheck

Auth + API reachability

Supports SimpliSafe 3 systems. Legacy SS2 systems are rejected with an explanation rather than an opaque upstream 404.

Related MCP server: mcp-hs4

Install

npm install -g simplisafe-mcp

Or add to .mcp.json:

{
  "mcpServers": {
    "simplisafe": {
      "command": "npx",
      "args": ["-y", "simplisafe-mcp"],
      "env": { "SIMPLISAFE_REFRESH_TOKEN": "${SIMPLISAFE_REFRESH_TOKEN}" }
    }
  }
}

Authentication — one browser login, once

SimpliSafe issues no API keys. The credential is an OAuth2 refresh token, minted by a browser login you perform one time:

git clone https://github.com/chrischall/simplisafe-mcp && cd simplisafe-mcp
node scripts/bootstrap-auth.mjs             # prints an authorize URL
# sign in (MFA included), then copy the com.simplisafe.mobile:// URL
node scripts/bootstrap-auth.mjs "<that URL>"

The token is written to .env (mode 0600) after being verified against the live API. SimpliSafe does not rotate refresh tokens, so it stays valid until you sign out of all devices in the SimpliSafe app — which is how you revoke it.

Capturing the code: open DevTools → Network and tick Preserve log before signing in; afterwards the browser fails to open a com.simplisafe.mobile://… link, and that failed entry's link address is what you paste. The code is single-use and expires in about two minutes.

Treat the resulting token like a house key: it grants full control of the alarm.

Confirmations

Arming, disarming, locking, unlocking and reading the PINs all ask you to confirm first. On a client that can show a confirmation prompt (Claude Code) you get the prompt, with the details below (unless MCP_CONFIRM_ELICITATION=off). On one that cannot (claude.ai, Claude Desktop) the first call sends nothing and returns a preview plus a confirmToken; only a repeat call with that token acts, once. The preview includes a plain statement of the physical consequence:

{
  "status": "confirmation-required",
  "confirmed": false,
  "dispatched": false,
  "action": "alarm.set_state",
  "preview": {
    "action": "set alarm state to away",
    "method": "POST",
    "path": "/ss3/subscriptions/7858153/state/away",
    "sid": 7858153,
    "locationName": "Home",
    "currentState": "OFF",
    "requestedState": "AWAY",
    "warning": "Arms ALL sensors including interior motion. Starts an exit delay; anyone still moving inside when it expires can trigger the siren and a monitoring-center dispatch."
  },
  "confirmToken": "…",
  "expiresAt": "…",
  "ttlSeconds": 600,
  "instruction": "Show this preview to the user verbatim and proceed only after they explicitly approve in chat. Then call again with confirmToken."
}

The token is bound to that tool, target and preview. The system is re-read on the second call, and if what would happen no longer matches what you approved — different arguments, or the alarm or lock state moved in between — it is refused (DRAFT_CHANGED) with a fresh preview. A token that was already used is refused too (TOKEN_REUSED).

variable

default

MCP_CONFIRM_MODE

ask-user

What a write does on a client that cannot show a confirmation prompt (claude.ai, Claude Desktop). ask-user: two steps — the first call does nothing and returns a preview plus a token, and the model must get your approval in chat before calling again with it. auto: the same two steps, but the model may use the token after reviewing the preview itself. refuse: writes are refused on such clients. A client that can show prompts (Claude Code) always gets the real prompt, unless MCP_CONFIRM_ELICITATION=off. An unrecognised value is treated as refuse.

MCP_CONFIRM_ELICITATION

on

off never shows a confirmation prompt, so every client gets the MCP_CONFIRM_MODE behaviour. Set it for a client that says it can show prompts but never does (the write hangs — opencode 2.0.x). Any other value is treated as on, with a warning on stderr.

MCP_CONFIRM_TTL_SECONDS

600

How long a token stays valid.

MCP_CONFIRM_SECRET

random per process

Signing key; set it only if tokens must survive a server restart.

Writes are verified

Once confirmed, a write executes and then re-reads the system to check what actually happened, reporting confirmed, in_progress (the exit delay is counting down), or unconfirmed. A 2xx is never treated as proof.

Shell access without the server

For quick one-off queries there's a curl-based skill in skills/simplisafe-api/ — same API, no MCP process, sharing the same refresh token.

Development

npm install
npm run build
npm test

Verified endpoint shapes live in docs/SIMPLISAFE-API.md, including several things that are easy to get backwards:

  • lock state is encoded 1 = locked, 2 = unlocked;

  • system version for routing is at location.system.version, not the top-level systemVersion;

  • events and doorlock control are not under the ss3/ prefix;

  • numEvents has an undocumented hard ceiling of 50;

  • settings.pins returns alarm codes in cleartext alongside harmless settings.

Disclaimer

Unofficial. Not affiliated with or endorsed by SimpliSafe. It uses the same private API the SimpliSafe mobile app uses, with your own account credentials. Use at your own discretion.

License

MIT

Available Tools

10 tools
simplisafe_get_eventsA
Read-only

Get recent events recorded by the base station — arm/disarm, sensor opens, lock and unlock, alarms, errors — newest first. Each event carries an ISO timestamp alongside the raw epoch seconds.

Inputs: sid, view, event_type, num_events, +1 more.

simplisafe_get_pinsA
DestructiveIdempotent

Read the system's user PINs (master, duress and named users). These are the live alarm codes and are returned in cleartext, so calling this puts them into the conversation. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a warning preview and a confirmToken and fetches nothing, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE).

Inputs: sid, confirmToken.

simplisafe_get_settingsA
Read-only

Get base-station settings for a system: entry/exit delays, alarm volume and duration, door chime, voice prompts, plus base-station health (wifi/cellular signal, wall power, backup battery, RF jamming). Does not include PINs — use simplisafe_get_pins for those.

Inputs: sid.

simplisafe_get_systemA
Read-only

Get the current state of one SimpliSafe system: alarm state, whether it is alarming, base-station connectivity, power/battery status and any pending base-station messages.

Inputs: sid.

simplisafe_healthcheckA
Read-only

Check that the server can authenticate to SimpliSafe and reach the API. Reports whether the refresh token is configured and working, the resolved user id, and how many active systems the account has. Start here when other tools fail.

Inputs: no named parameters.

simplisafe_list_locksA
Read-only

List the smart locks on a system with their current state (locked / unlocked / jammed), lock and keypad battery status, and keypad connectivity. Returns the serial that simplisafe_set_lock_state takes. Polls the base station fresh by default, because a stale answer to "is my door locked?" is worse than a slow one.

Inputs: sid, force_update.

simplisafe_list_sensorsA
Read-only

List the sensors and devices paired to a system — entry sensors, motion, glass break, smoke/CO, keypads, sirens and locks — with battery, offline and triggered status. Filter by type with type_name (e.g. "entry", "motion_v2", "lock").

Inputs: sid, type_name, force_update, problems_only.

simplisafe_list_systemsA
Read-only

List the SimpliSafe systems on this account with their current alarm state (off/home/away), alarming status, connectivity and power status. Start here to get the sid other tools take.

Inputs: no named parameters.

simplisafe_set_alarm_stateA
DestructiveIdempotent

Arm or disarm the alarm system: "off" (disarm), "home" (perimeter only) or "away" (all sensors). Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). This physically changes a security system: disarming leaves the house unmonitored, and arming can trigger a siren and a monitoring-center dispatch. After executing, the new state is verified by re-reading the system.

Inputs: state (required), sid, confirmToken.

simplisafe_set_lock_stateA
DestructiveIdempotent

Lock or unlock a SimpliSafe smart lock. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE). Unlocking physically opens a door lock, so it is gated even though it is technically reversible. After executing, the result is verified by re-reading the lock state.

Inputs: state (required), serial (required), sid, confirmToken.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.2/5.0

    Scored across 10 tools

    Disambiguation4/5

    Most tools are clearly separated by resource and action (events, pins, settings, sensors, locks, alarm state, lock state). The main overlaps are simplisafe_list_systems vs simplisafe_get_system (both return alarm/connectivity state, distinguished mainly by 'start here for sid' vs 'one system'), and simplisafe_list_locks vs simplisafe_list_sensors with type_name='lock', which surface much of the same lock data. Descriptions do enough to steer an agent, but these pairs could be confused.

    Naming Consistency4/5

    Nearly every tool follows the simplisafe_verb_noun pattern (list_systems, get_events, get_pins, set_alarm_state, set_lock_state). The only deviation is simplisafe_healthcheck, a bare noun with no verb, though it is still unambiguous. Verb choice (list vs get) is used meaningfully and consistently.

    Tool Count5/5

    Ten tools is well within the sweet spot and each one maps to a distinct resource or action in the alarm-system domain. Nothing feels padded: read tools for systems, sensors, locks, events, pins and settings, plus the two meaningful write operations.

    Completeness4/5

    The surface covers discovery, monitoring, diagnostics and the two core control actions (arm/disarm, lock/unlock), including confirmation gating and post-action verification. Gaps remain on the write side: settings are read-only (no set_settings) and PINs can be read but not created or changed, and cameras are absent. These are workable limitations rather than dead ends for the main workflow.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      MCP server for controlling Nuki Smart Locks via Home Assistant, enabling lock/unlock, intercom buzzing, and battery checks.
      1
      MIT
    • A
      license
      B
      quality
      D
      maintenance
      MCP server for controlling HomeSeer HS4 with safe, auditable, and guarded write operations.
      63
      1
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      MCP server for the entire Shelly smart-home ecosystem, enabling local-first control, automation, and energy monitoring of Shelly devices with cloud fallback.
      47
      37 PyPI
      MIT
    • F
      license
      Not graded
      quality
      C
      maintenance
      MCP server for controlling Somfy TaHoma devices locally via the box's API, without cloud dependency.
      -