simplisafe-mcp
This server lets you monitor and control a SimpliSafe 3 home security system from an MCP client like Claude.
Check systems — list systems on the account with alarm state, connectivity and power; get one system's detailed status and base-station messages
Review sensors and locks — list sensors/devices with battery, offline and triggered status (filterable by type or problems only), and list smart locks with locked/unlocked/jammed state
Review history and settings — recent base-station events (arm, disarm, opens, alarms, errors), plus entry/exit delays, volumes and base-station health
Read alarm PINs — returns live codes in cleartext (requires confirmation first)
Change physical state — arm home/away or disarm the alarm, and lock or unlock doors (both require confirmation and are verified by re-reading state afterward)
Diagnose — healthcheck for auth and API reachability
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@simplisafe-mcp check if my alarm is armed"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 | |
| Systems on the account with current alarm state |
| One system's state, connectivity, base-station messages |
| Sensors with battery / offline / triggered status, filterable |
| Smart locks with locked / unlocked / jammed state |
| Recent base-station events (arm, disarm, opens, alarms); |
| Entry/exit delays, volumes, base-station health |
| Alarm PINs — cleartext, asks you to confirm first |
| Arm home / arm away / disarm — asks you to confirm first |
| Lock / unlock a door — asks you to confirm first |
| 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-mcpOr 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 | |
|
| What a write does on a client that cannot show a confirmation prompt (claude.ai, Claude Desktop). |
|
|
|
|
| How long a token stays valid. |
| 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 testVerified 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-levelsystemVersion;events and doorlock control are not under the
ss3/prefix;numEventshas an undocumented hard ceiling of 50;settings.pinsreturns 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 toolssimplisafe_get_eventsARead-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_pinsADestructiveIdempotent
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_settingsARead-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_systemARead-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_healthcheckARead-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_locksARead-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_sensorsARead-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_systemsARead-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_stateADestructiveIdempotent
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_stateADestructiveIdempotent
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
Scored across 10 tools
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.
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.
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.
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
Related MCP Connectors
MCP server wrapping the Tesla Fleet API and TeslaMate API
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
The official Planning Center MCP server for interacting with your ministry's data.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceMCP server for controlling Nuki Smart Locks via Home Assistant, enabling lock/unlock, intercom buzzing, and battery checks.1MIT
- AlicenseBqualityDmaintenanceMCP server for controlling HomeSeer HS4 with safe, auditable, and guarded write operations.631MIT
- AlicenseAqualityBmaintenanceMCP server for the entire Shelly smart-home ecosystem, enabling local-first control, automation, and energy monitoring of Shelly devices with cloud fallback.4737 PyPIMIT
- FlicenseNot gradedqualityCmaintenanceMCP server for controlling Somfy TaHoma devices locally via the box's API, without cloud dependency.-