simplisafe-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SIMPLISAFE_REFRESH_TOKEN | Yes | The OAuth2 refresh token for accessing the SimpliSafe API. Obtained via a one-time browser login. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| simplisafe_list_systemsA | 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 |
| simplisafe_get_systemA | 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. |
| simplisafe_get_settingsA | 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. |
| simplisafe_get_pinsA | 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). |
| simplisafe_list_sensorsA | 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 |
| simplisafe_list_locksA | List the smart locks on a system with their current state (locked / unlocked / jammed), lock and keypad battery status, and keypad connectivity. Returns the |
| simplisafe_get_eventsA | 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. |
| simplisafe_set_alarm_stateA | 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. |
| simplisafe_set_lock_stateA | 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. |
| simplisafe_healthcheckA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools target a distinct resource+action (systems, sensors, locks, settings, events, pins, healthcheck). The only mild overlap is list_sensors, which explicitly includes locks, versus the dedicated list_locks, and get_system vs list_systems for a single system — but the descriptions clarify these boundaries well.
Every tool follows a predictable simplisafe_<verb>_<noun> pattern using consistent verbs (list_*, get_*, set_*). No mixing of camelCase, tense, or verb styles across the set.
Ten tools is well-scoped for a home-security control/monitoring server, and each one earns its place: multiple read tools for distinct resources plus the two state-changing control tools.
Read coverage is strong (systems, sensors, locks, settings, events, pins, health) and arm/disarm plus lock control are present, covering the core lifecycle. There are minor gaps — no set_pins despite get_pins, and no way to update base-station settings — but core monitoring and control workflows are complete.