Connect Verkada to ChatGPT: Analyze Security Footage & Event Data

If you need to connect Verkada to ChatGPT to automate physical security operations, investigate tailgating incidents, or analyze environmental sensor data, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's JSON-RPC tool calls and Verkada's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses Claude, check out our guide on connecting Verkada to Claude or explore our broader architectural overview on connecting Verkada to AI Agents.

Giving a Large Language Model (LLM) read and write access to a physical security ecosystem like Verkada is an immense engineering challenge. You have to handle dense telemetry from environmental sensors, navigate strict pagination on License Plate Recognition (LPR) endpoints, and map access control events to camera footage.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Verkada, connect it natively to ChatGPT, and execute complex physical security workflows using natural language.

Stop writing boilerplate API integration code. Let Truto generate secure, managed MCP servers for your AI agents in seconds. :::

The Engineering Reality of the Verkada API

A custom MCP server is a self-hosted integration layer that translates an LLM's natural language intent into structured REST API requests.

While Anthropic's open MCP standard provides a predictable way for models to discover tools, implementing it against Verkada's API requires dealing with domain-specific quirks. If you decide to build a custom MCP server for Verkada, you are responsible for the entire API lifecycle. Here are the specific integration challenges you will face:

Helix Event Complexity and Timestamp Precision

Verkada's Helix API allows you to push and query third-party events (like POS transactions or factory floor alerts) alongside video footage. However, retrieving a specific Helix event requires exact precision. The list_all_verkada_helix_events endpoint does not support fuzzy searching - it demands the exact time_ms (Unix timestamp in milliseconds), the camera_id, and the event_type_uid. If your LLM attempts to search for "events from yesterday," the custom MCP server must implement complex logic to translate that into specific timestamp queries, or else use the verkada_helix_events_search endpoint and paginate through massive arrays of unstructured attribute data.

Massive Sensor Data Payloads

Verkada's SV11 and SV20 series environment sensors return highly dense arrays of telemetry data. A single request to list_all_verkada_sensor_data returns readings for temperature, humidity, noise level, PM2.5, vape index, TVOC, and CO2, captured at 1-second intervals. If you expose this endpoint directly to an LLM without strict start_time and end_time boundaries, the returned JSON will instantly blow up the model's context window. Your MCP server must force the LLM to restrict its query windows.

LPR Pagination and Query Limits

License Plate Recognition (LPR) endpoints in Verkada are strictly guarded. When querying list_all_verkada_lpr_images or list_all_verkada_lpr_timestamps, you are hard-limited to querying one single camera per request. You cannot ask for "all instances of this license plate across the organization." Furthermore, pagination is capped at a strict 200 items per page. The LLM cannot ingest 10,000 license plate reads at once; it must be instructed to utilize cursors carefully, passing the values back exactly as received.

Rate Limiting and Asynchronous Batching

Verkada enforces strict rate limits across its Command API. Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When the Verkada API returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (or the custom agent executing the MCP tool) is strictly responsible for handling the 429 error and implementing its own retry or backoff logic.

Additionally, endpoints like verkada_helix_events_bulk_create operate asynchronously. They accept up to 1,000 events and return a 202 Accepted status, meaning the job is queued, not completed. Your LLM must be taught to parse the resulting batch ID and subsequently poll get_single_verkada_batch_job_by_id to verify execution.

The Managed MCP Approach

Instead of forcing your engineering team to build, host, and maintain a custom translation layer for Verkada's API quirks, you can use Truto.

Truto dynamically generates MCP tools from Verkada's API documentation and OpenAPI specifications. Rather than hand-coding tool definitions, Truto reads the underlying schema and exposes a standardized JSON-RPC 2.0 endpoint. When ChatGPT calls a tool, Truto translates the flat argument payload into the correct query parameters and request bodies, executes the request against Verkada, and normalizes the response.

1. How to Create the Verkada MCP Server

You can generate an MCP server for any connected Verkada account via the Truto UI or programmatically via the API.

Method A: Via the Truto UI

1. Navigate to the Integrated Accounts page in your Truto dashboard.
2. Select your active Verkada connection.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., restrict to read-only methods or specific tags like "cameras" or "access").
6. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method B: Via the API For platform builders provisioning servers programmatically, send a POST request to the Truto API. This validates that the Verkada integration has AI-ready tools and returns a cryptographic token URL.

// POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp
// Authorization: Bearer {truto_api_key}
 
{
  "name": "Verkada SOC Analyst AI",
  "config": {
    "methods": ["read"],
    "tags": ["cameras", "sensors", "access"]
  },
  "expires_at": "2026-12-31T23:59:59Z"
}

The response contains the secure URL you will provide to ChatGPT:

{
  "id": "mcp_srv_998877",
  "name": "Verkada SOC Analyst AI",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

2. How to Connect the MCP Server to ChatGPT

Once you have the Truto MCP URL, you must configure ChatGPT to communicate with it. You can do this through the ChatGPT interface or via a manual Server-Sent Events (SSE) configuration file if you are running local agent wrappers.

Method A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
2. Toggle Developer mode to ON (MCP support requires this flag).
3. Under the MCP servers / Custom connectors section, click Add new server.
4. Enter a descriptive name (e.g., "Verkada Security Ops").
5. Paste the Truto MCP URL into the Server URL field.
6. Click Save. ChatGPT will perform an initialization handshake, pull the Verkada tool definitions, and make them available in your session.

Method B: Via Manual Config File (SSE Transport) If you are orchestrating agents locally or using a framework that reads standard MCP config files, you can define the server using the official SSE transport package. Create a verkada_mcp.json file:

{
  "mcpServers": {
    "verkada": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Security and Access Control

Giving an LLM access to physical security hardware is a high-risk operation. Truto's MCP implementation provides strict perimeter controls at the server level, ensuring the model cannot perform unauthorized actions even if prompted maliciously.

• Method Filtering: By defining methods: ["read"] during server creation, Truto physically strips out all write, update, and delete tools before the LLM ever sees them. The model literally does not know how to unlock a door or delete a user.
• Tag Filtering: You can restrict the MCP server's scope to specific API domains. Passing tags: ["sensors"] ensures the LLM can only query environmental data, entirely blocking its access to cameras or access control logs.
• Expiration Enforcement: The expires_at configuration natively schedules a distributed cleanup job. Once the timestamp passes, the routing token is destroyed in the edge datastore, immediately terminating all LLM access.
• Secondary Authentication: Enabling require_api_token_auth: true forces the client to pass a valid Truto API token in the headers alongside the connection URL. This prevents unauthorized execution if the MCP URL is accidentally leaked into standard application logs.

Verkada Hero Tools

When ChatGPT initializes the connection, Truto dynamically builds tool definitions based on the Verkada API schema. Here are the highest-leverage tools available for physical security automation.

Search Helix Events

Tool: verkada_helix_events_search Searches for third-party metadata events (Helix) injected into Verkada Command by camera, event type, time range, keywords, or custom attribute filters.

"Search the Verkada Helix events for camera 4f3a-9b2c over the last 6 hours where the POS transaction attribute 'flagged' is true."

Query Environment Sensor Data

Tool: list_all_verkada_sensor_data Extracts massive arrays of environmental telemetry (temperature, AQI, TVOC, vape index) for a specific device within a strict time range.

"Get the sensor data for device SV11-B992 between 14:00 and 15:00 yesterday. Look specifically at the vape_index and pm_2_5 readings."

List LPR Read Events

Tool: list_all_verkada_lpr_images Retrieves detected license plate numbers, confidence scores, timestamps, and cropped image URLs from a specific LPR-enabled camera.

"Pull the latest 50 license plate reads from the East Gate camera. Filter the results for any plates matching XYZ-1234."

Audit Access Control Events

Tool: list_all_verkada_access_events Lists card swipes, remote unlocks, door forced open alerts, and tailgating events within a configurable time range, filterable by user or site.

"List all access control events for the Server Room door between midnight and 4:00 AM today. Did any swipe result in an 'access denied' notification?"

Administer Remote Door Unlocks

Tool: verkada_doors_user_unlock Executes a remote door unlock command on behalf of a specific user, evaluating that user's permission set before firing the relay.

"Execute a user unlock on the Front Lobby door on behalf of user ID usr_998877. Verify the door status afterward."

Query Occupancy Trends

Tool: list_all_verkada_occupancy_trends Extracts historical occupancy and people-counting data points for a specific camera and preset zone.

"Query the occupancy trends for the Cafeteria camera using preset ID 12. What was the peak concurrent people count during the lunch hour?"

To view the complete schema details and the remaining tools available for this connector, visit the Verkada integration page.

Workflows in Action

AI agents excel at orchestrating physical security investigations by correlating data across Verkada's siloed product lines (Access Control, Cameras, and Sensors).

Scenario 1: Tailgating Investigation (Access + Camera)

When an unauthorized entry is suspected, SOC analysts typically have to cross-reference access control logs with camera footage manually. An AI agent can perform this correlation instantly.

"Check who swiped into the Server Room between 2:00 AM and 3:00 AM today. Once you have the access events, pull the closest camera thumbnail for the exact timestamp of any successful entries to verify who actually walked through."

Execution Steps:

1. The agent calls list_all_verkada_access_events passing the door_id for the Server Room and the specific Unix timestamps for start_time and end_time.
2. It parses the response, identifying a successful access_granted event for a specific employee at 02:14:33.
3. The agent extracts the camera_id associated with that door from the door_info payload.
4. It calls verkada_thumbnails_get_image passing the camera_id and the exact timestamp (02:14:33) to retrieve the raw binary data of the JPEG image.

Result: The agent returns the text log of the user who badged in, along with the image URL showing that a second, unbadged person caught the door before it closed.

sequenceDiagram
    participant User
    participant ChatGPT
    participant Truto as Truto MCP
    participant Verkada as Verkada API
    User->>ChatGPT: "Check who swiped into the server room..."
    ChatGPT->>Truto: call list_all_verkada_access_events
    Truto->>Verkada: GET /access/events
    Verkada-->>Truto: Return event list
    Truto-->>ChatGPT: Return JSON
    ChatGPT->>Truto: call verkada_thumbnails_get_image
    Truto->>Verkada: GET /cameras/thumbnail
    Verkada-->>Truto: Return image data
    Truto-->>ChatGPT: Return result
    ChatGPT-->>User: "Here is the access log and corresponding image."

Scenario 2: Vaping/Air Quality Incident (Sensor + Helix)

School administrators or facility managers often need to correlate environmental sensor spikes with custom metadata events to build a timeline of incidents.

"Review the sensor data for the West Restroom device over the last 2 hours. If the vape index spiked above 50, log a new Helix event to the hallway camera outside that restroom noting the incident time and a 'vaping_suspected' attribute."

Execution Steps:

1. The agent calls list_all_verkada_sensor_data, calculating the start_time and end_time Unix timestamps for the last two hours, targeting the specific sensor device_id.
2. It parses the returned array, iterating through the 1-second intervals to locate any object where vape_index > 50.
3. Upon detecting a spike at 10:45 AM, the agent constructs a Helix payload.
4. It calls create_a_verkada_helix_event, passing the camera_id of the adjacent hallway camera, the time_ms corresponding to the spike, the pre-configured event_type_uid, and a custom attribute of {"incident_type": "vaping_suspected"}.

Result: The agent successfully identifies the environmental anomaly and automatically tags the corresponding video footage in the Verkada Command dashboard, allowing administrators to review the hallway footage immediately preceding the spike.

flowchart TD
    A["Call list_all_verkada_sensor_data"] --> B{"Vape Index > 50?"}
    B -->|"Yes (Spike detected)"| C["Extract exact timestamp"]
    B -->|"No"| D["End workflow"]
    C --> E["Call create_a_verkada_helix_event"]
    E --> F["Verkada Command UI updated<br>with tagged footage"]

Wrapping Up

Connecting ChatGPT to Verkada transforms passive physical security systems into proactive, agentic workflows. Instead of forcing analysts to manually scrub timelines, correlate access badges, and export sensor spreadsheets, you can orchestrate your entire Command environment using natural language.

By leveraging a managed MCP server via Truto, you bypass the brutal engineering overhead of handling Verkada's massive sensor arrays, strict LPR pagination, and rate limit architectures. The tools are dynamically generated, the authentication is handled securely at the edge, and your engineers can focus on building AI capabilities rather than maintaining integration boilerplate.