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 distinct resources and actions, and the descriptions clearly explain scope differences. Minor overlap exists between get_system/list_systems and list_locks/list_sensors, but the descriptions are specific enough to prevent serious confusion.
Tool names consistently use a simplisafe_ prefix and snake_case, with a predictable get_/set_/list_ verb pattern. simplisafe_healthcheck is the one deviation, but the overall naming convention is still coherent and easy to follow.
Ten tools is a well-scoped surface for a SimpliSafe integration, covering account/system lookup, alarm control, lock control, sensors, events, settings, PINs, and connection health. Each tool has a clear purpose and none feels redundant.
Core monitoring and control workflows are covered: listing systems, reading state, arming/disarming, listing sensors and locks, locking/unlocking, fetching events, viewing settings, and reading PINs. The main gaps are write operations for settings and PIN management, but common agent workflows should not hit dead ends.