How do I use Frigate MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Frigate MCP Server show me recent motion events from the front door camera" 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.

Frigate MCP Server

by dedsxc

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Frigate MCP Server

A Model Context Protocol (MCP) server for Frigate NVR, enabling AI assistants to interact with your Frigate security camera system.

Python Version License

🌟 Features

Camera Management: List and monitor all configured cameras
Event Detection: Query detection events with filtering by camera, object type, and time
Live Snapshots: Get current or historical camera snapshots
Recordings: Access recording summaries and segments
System Stats: Monitor Frigate performance, detector speed, and camera FPS
Configuration: Retrieve complete Frigate configuration

Related MCP server: OBSBOT Camera MCP Server

📋 Prerequisites

Python 3.10 or higher
A running Frigate NVR instance
Access to the Frigate HTTP API

🚀 Installation

1. Clone the repository

git clone https://github.com/yourusername/frigate-mcp.git
cd frigate-mcp

2. Create a virtual environment

python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

3. Install dependencies

pip install -e .

4. Configure environment

Create a .env file in the project root:

# Required: URL of your Frigate instance
FRIGATE_FRIGATE_URL=http://localhost:5000

# Optional: API key if authentication is required
# FRIGATE_API_KEY=your_secret_key_here

# Optional: HTTP timeout in seconds (default: 30)
# FRIGATE_TIMEOUT=30

🔧 Configuration

The server uses environment variables for configuration. You can set them in:

.env file (recommended for development)
Environment variables (recommended for production)

Configuration Options

Variable	Description	Default	Required
`FRIGATE_FRIGATE_URL`	Base URL of Frigate instance	`http://localhost:5000`	No
`FRIGATE_API_KEY`	API key for authentication	None	No
`FRIGATE_TIMEOUT`	HTTP request timeout (seconds)	`30`	No
`FRIGATE_SERVER_HOST`	Server host for SSE/HTTP modes	`0.0.0.0`	No
`FRIGATE_SERVER_PORT`	Server port for SSE/HTTP modes	`8000`	No

Example Configurations

Local Frigate instance:

FRIGATE_FRIGATE_URL=http://localhost:5000

Remote Frigate with authentication:

FRIGATE_FRIGATE_URL=http://192.168.1.100:5000
FRIGATE_API_KEY=your_secret_key
FRIGATE_TIMEOUT=60

🎯 Usage

The server supports three operational modes:

1. STDIO Mode (Default)

For direct integration with MCP clients like Claude Desktop:

python -m frigate_mcp.server
# or
frigate-mcp

2. SSE Mode (Server-Sent Events)

For web-based clients with real-time updates:

frigate-mcp-sse

The server will start at http://localhost:8000/sse (configurable via environment variables).

Features:

Real-time event streaming
WebSocket-like experience over HTTP
Easy to debug in browser dev tools
Compatible with web applications

3. HTTP Mode (REST API)

For production deployments and API access:

STDIO Mode (for MCP clients):

python -m frigate_mcp.server

SSE Mode (for web clients):

frigate-mcp-sse

HTTP Mode (for REST API):

frigate-mcp-http

Integrating with MCP Clients

Claude Desktop (STDIO Mode)

Testing the Connection

Run the included test script to verify your Frigate connection:

python test_connection.py

Expected output:

============================================================
Frigate MCP Server - Connection Test
============================================================

🔧 Frigate Configuration:
   URL: http://localhost:5000
   API URL: http://localhost:5000/api
   Timeout: 30s

📹 Testing /api/config (cameras)...
   ✅ Found 1 camera(s)
      - front_door: enabled

📊 Testing /api/stats...
   ✅ Frigate version: 0.16.3
   ✅ Detectors: ['coral']
   ✅ Active cameras: ['front_door']
...

Running the MCP Server

Start the server in stdio mode (for MCP clients):

python -m frigate_mcp.server

Claude Desktop (STDIO Mode)

Add to your MCP client configuration (e.g., Claude Desktop config.json):

{
  "mcpServers": {
    "frigate": {
      "command": "/path/to/frigate-mcp/.venv/bin/python",
      "args": ["-m", "frigate_mcp.server"],
      "env": {
        "FRIGATE_FRIGATE_URL": "http://localhost:5000"
      }
    }
  }
}

Web Clients (SSE Mode)

Connect to the SSE endpoint for real-time updates:

const eventSource = new EventSource('http://localhost:8000/sse');

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received:', data);
};

REST API (HTTP Mode)

Make standard HTTP requests:

# Get cameras
curl http://localhost:8000/tools/get_cameras

# Get events
curl http://localhost:8000/tools/get_events?limit=5

# Get stats
curl http://localhost:8000/tools/get_stats

Or use any HTTP client:

import requests

response = requests.post(
    'http://localhost:8000/tools/get_events',
    json={'camera': 'front_door', 'limit': 10}
)
print(response.json())   "frigate": {
      "command": "/path/to/frigate-mcp/.venv/bin/python",
      "args": ["-m", "frigate_mcp.server"],
      "env": {
        "FRIGATE_FRIGATE_URL": "http://localhost:5000"
      }
    }
  }
}

🛠️ Available Tools

The server provides 7 MCP tools for interacting with Frigate:

1. `get_cameras()`

List all configured cameras with their status and properties.

Returns:

[
  {
    "name": "front_door",
    "enabled": true,
    "width": 1920,
    "height": 1080,
    "fps": 5
  }
]

2. `get_events(camera, label, limit)`

Get recent detection events with optional filtering.

Parameters:

camera (optional): Filter by camera name
label (optional): Filter by object type (person, car, dog, etc.)
limit (default: 10): Maximum events to return (1-100)

Example:

get_events(camera="front_door", label="person", limit=5)

Returns:

[
  {
    "id": "1234567890.123456-abcdef",
    "camera": "front_door",
    "label": "person",
    "start_time": 1704067200.5,
    "end_time": 1704067205.8,
    "has_clip": true,
    "has_snapshot": true,
    "zones": ["entrance"],
    "thumbnail": "http://localhost:5000/api/events/1234.../thumbnail.jpg"
  }
]

3. `get_stats()`

Get Frigate system statistics and performance metrics.

Returns:

{
  "service": {
    "uptime": 86400,
    "version": "0.16.3",
    "storage": {...}
  },
  "detectors": {
    "coral": {
      "inference_speed": 8.5,
      "detection_start": 1704067200.0
    }
  },
  "cameras": {
    "front_door": {
      "camera_fps": 5.0,
      "process_fps": 5.0,
      "detection_fps": 1.2
    }
  }
}

4. `get_event_details(event_id)`

Get comprehensive details about a specific event.

Parameters:

event_id: Unique event identifier

Returns:

{
  "id": "1234567890.123456-abcdef",
  "camera": "front_door",
  "label": "person",
  "start_time": 1704067200.5,
  "end_time": 1704067205.8,
  "duration": 5.3,
  "score": 0.87,
  "zones": ["entrance"],
  "has_clip": true,
  "has_snapshot": true,
  "media": {
    "thumbnail": "http://localhost:5000/api/events/.../thumbnail.jpg",
    "snapshot": "http://localhost:5000/api/events/.../snapshot.jpg",
    "clip": "http://localhost:5000/api/events/.../clip.mp4"
  }
}

5. `get_snapshot(camera, timestamp)`

Get a snapshot URL from a specific camera.

Parameters:

camera: Camera name
timestamp (optional): Unix timestamp for historical snapshot

Returns:

{
  "camera": "front_door",
  "timestamp": "latest",
  "url": "http://localhost:5000/api/front_door/latest.jpg",
  "description": "Snapshot from front_door (latest)"
}

6. `get_recordings(camera, date)`

Get recording information for a specific camera and date.

Parameters:

camera: Camera name
date (optional): Date in YYYY-MM-DD format (defaults to today)

Returns:

{
  "camera": "front_door",
  "date": "2024-01-01",
  "recordings_count": 24,
  "total_duration": 86400,
  "recordings": [
    {
      "day": "2024-01-01",
      "hour": "10",
      "duration": 3600,
      "events": 5
    }
  ]
}

7. `get_config()`

Get Frigate configuration summary.

Returns:

{
  "cameras": ["front_door", "backyard", "garage"],
  "detectors": ["coral"],
  "mqtt": {
    "enabled": true,
    "host": "localhost"
  },
  "model": "path/to/model.tflite",
  "version": "0.16.3"
}

🏗️ Project Structure

frigate-mcp/
├── src/
│   └── frigate_mcp/
│       ├── __init__.py       # Package metadata
│       ├── config.py         # Configuration management
│       └── server.py         # MCP server & tools
├── test_connection.py        # Connection test script
├── pyproject.toml           # Project dependencies
├── .env                     # Environment variables (not in git)
└── README.md                # This file

Made with ❤️ for the Frigate and MCP communities

Available Tools

7 tools

get_camerasA

Get the list of all cameras configured in Frigate.

Returns a list of cameras with their names, status, and configuration details.

Returns: List of camera objects with name, enabled status, and other properties

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It mentions the return format (list of cameras with names, status, config) but does not explicitly state that the operation is read-only or discuss any side effects, authorization, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences and a return line. No wasted words; front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema (implied), the description is fairly complete. It names the returned fields (name, enabled status, other properties). However, 'other properties' is vague, and the description could be slightly more specific.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so schema coverage is 100%. The description does not need to add parameter information, and it does not. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get the list of all cameras configured in Frigate' with a specific verb and resource, and it distinguishes itself from sibling tools like get_events or get_recordings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (when you need the list of all cameras) but does not provide explicit guidance on when not to use or mention alternatives. Usage context is clear but not elaborated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_configA

Get the complete Frigate configuration.

Retrieves the full Frigate configuration including all cameras, detectors, motion settings, and system configuration.

Returns: Complete Frigate configuration dictionary

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. States it returns a dict, which is a read operation with no side effects. No disclosure of auth needs or rate limits but acceptable for simple read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no waste. Front-loaded with purpose, then scope, then return type.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero params, output schema present, and clear description of what is returned (full config including all cameras, etc.), the description is fully adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; baseline is 4. Description adds no param info but not needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Get' and resource 'complete Frigate configuration', listing included components (cameras, detectors, motion, system). Distinguishes from siblings like get_cameras which are partial.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for retrieving full configuration, but no explicit when-to-use versus siblings or prerequisites. Could be improved by noting alternatives for specific subsets.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_event_detailsB

Get detailed information about a specific detection event.

Retrieves comprehensive details including zones, thumbnails, clips, and timeline information for a single event.

ParametersJSON Schema

Name	Required	Description	Default
`event_id`	Yes	The unique ID of the event to retrieve

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description lacks behavioral details like read/write nature, authentication needs, rate limits, or potential large response sizes. Only states 'retrieves', which is implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with verb and resource. No wasted words; second sentence adds value by listing retrieved details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Has output schema (context indicates), so return values are covered. However, missing behavioral and usage guidance leaves gaps for a simple tool. Adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter (event_id) has a clear schema description; tool description adds minimal extra meaning beyond 'specific detection event'. With 100% schema coverage, baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it retrieves detailed information for a specific detection event, listing included details (zones, thumbnails, clips, timeline). Distinguishes from siblings like get_events (list) and get_snapshot (image).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs siblings like get_events (list) or get_recordings. No exclusions or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_eventsB

Get recent detection events from Frigate.

Retrieves events based on optional filters for camera and detected object label.

ParametersJSON Schema

Name	Required	Description
`label`	No	Filter by detected object label like 'person', 'car', 'dog' (optional)
`limit`	No	Maximum number of events to return (default: 10, max: 100)
`camera`	No	Filter by specific camera name (optional)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavioral traits. It says 'recent' but doesn't define the time range or ordering. No mention of read-only nature, rate limits, or whether events are deleted after retrieval. Minimal behavioral info beyond basic retrieval.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose. No unnecessary words. Well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values are covered. However, the description lacks context on recency definition, default limit, pagination, and how this tool relates to sibling event tools. Moderate completeness for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for each parameter (label, limit, camera). The description adds that events are 'recent' and filters are optional, but this largely mirrors the schema. No new semantic detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it gets recent detection events from Frigate with optional filters. Verb 'get' with resource 'events' is specific. However, it doesn't differentiate from sibling 'get_event_details' which likely retrieves a single event by ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like 'get_event_details' or 'get_recordings'. No mention of prerequisites or limitations. Usage context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recordingsA

Get recording information for a specific camera.

Retrieves the recording summary including available recordings and storage information for a camera on a specific date.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format (optional, defaults to today)
`camera`	Yes	Name of the camera

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It indicates a read operation but does not explicitly state safety, idempotency, or side effects. The typical 'get' semantics are implied but not confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the main action. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description need not detail return values. It mentions recording summary and storage info, providing adequate context for the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3. The description echoes 'specific camera' and 'specific date' but adds no meaning beyond the schema's own parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves recording information for a specific camera, including summary and storage info. It distinguishes itself from sibling tools like get_cameras and get_events through its focus on recordings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving recording data but provides no explicit guidance on when to use versus alternatives. It does not mention exclusions or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_snapshotA

Get a snapshot from a specific camera.

Returns the URL to access a snapshot image from the camera, either current or from a specific timestamp.

ParametersJSON Schema

Name	Required	Description	Default
`camera`	Yes	Name of the camera
`timestamp`	No	Optional Unix timestamp for historical snapshot

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool returns a URL and can retrieve current or timestamped snapshots, but does not mention potential failures, permission needs, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no unnecessary words. Efficiently communicates the tool's function and return value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema, the description appropriately focuses on purpose and parameter usage. It covers the main functionality, but could include more usage guidance for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds that 'timestamp' is optional and used for historical snapshots, which aligns with schema but does not add significant new meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it gets a snapshot from a specific camera and explains it returns a URL for current or historical image. This differentiates it from sibling tools which deal with cameras, config, events, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving snapshot images but does not provide explicit guidance on when to use this tool versus alternatives or mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_statsA

Get Frigate system statistics and performance metrics.

Returns information about CPU usage, memory, detector performance, camera FPS, and detection metrics.

Returns: Dictionary containing system stats, detector info, and camera metrics

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must compensate. It describes the return type (dictionary) and contents but does not disclose any behavioral traits like idempotency, authorization needs, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences cover the purpose, scope, and return value without redundancy. The structure is clear though slightly verbose with the 'Returns:' clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an output schema (context signal 'Has output schema: true'), the description fully informs the agent about the tool's purpose and the nature of its output, leaving no critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description adds no parameter details because none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves 'Frigate system statistics and performance metrics' and lists specific data (CPU, memory, detector performance, camera FPS, detection metrics). This distinguishes it from sibling tools like get_cameras or get_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for system monitoring but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

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

7 tool updatesv0.1.0Jul 10, 2026
- First observedget_cameras
- First observedget_config
- First observedget_event_details
- First observedget_events
- First observedget_recordings
- First observedget_snapshot
- First observedget_stats

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-10 05:00 across 7 tools

Disambiguation5/5

Each tool has a clear and distinct purpose: listing cameras, retrieving config, listing/details of events, recordings, snapshots, and stats. No two tools overlap significantly, so an agent can easily distinguish them.

Naming Consistency5/5

All tool names follow a consistent 'get_' prefix with snake_case (e.g., get_cameras, get_event_details). The pattern is uniform and predictable.

Tool Count5/5

With 7 tools covering key read-only aspects of a surveillance system (cameras, config, events, recordings, snapshots, stats), the count is well-scoped and neither too sparse nor excessive.

Completeness4/5

The set covers essential read operations for Frigate, including event details and recordings. Minor gaps like write operations (e.g., update event, set config) are absent, but this may be intentional for a read-only server.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mytesla.ioOAuth
io.mytesla
Control your Tesla from your AI assistant - climate, charging, access, and security.
Home Automation & IoT Travel & Transportation
2
SignageSpaceOAuth
com.signagespace
Manage digital signage screens, playlists and media from your AI assistant.
Content Management Systems Entertainment & Media
1
northflank A
io.usefulapi
Inspect and control your Northflank projects, services, jobs, and builds from your AI assistant.
Cloud Platforms CI/CD & DevOps
172
SimplyPrint: 3D Print Farm Management B
io.simplyprint
3D print farm management for AI. Monitor, queue, and control prints on your SimplyPrint account.
App Automation Virtualization
7521

Related MCP Servers

Enhanced Home Assistant MCP
Home Automation & IoT App Automation Autonomous Agents
gilberth
A
license
Not graded
quality
D
maintenance
Enables comprehensive control and monitoring of Home Assistant smart home devices, automations, scenes, and system management through AI assistants. Supports lights, climate, media players, notifications, history tracking, and advanced automation workflows.
Updated a year ago (2025-06-20 04:16 UTC)
4 npm
2
MIT
OBSBOT Camera MCP Server
Image & Video Processing Multimedia Processing Autonomous Agents
Radar105
A
license
B
quality
D
maintenance
Enables PTZ camera control with gimbal positioning, snapshots, and AI visual analysis for OBSBOT and UVC cameras. Supports autonomous scanning patterns and integrates with vision-language models for real-time camera analysis.
Updated 8 months ago (2026-01-11 14:46 UTC)
7
1
MIT
Home Assistant MCP Server
Home Automation & IoT App Automation
mjrestivo16
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Home Assistant smart home devices through natural language. Control devices, manage automations, query entity states, and retrieve historical data across your home automation system.
Updated 9 months ago (2025-12-04 07:04 UTC)
1
MIT
MCP Frigate Optimizer
Monitoring Observability Home Automation & IoT
avargas2026
A
license
Not graded
quality
D
maintenance
Enables AI agents to audit, manage, and optimize Frigate NVR configurations, including LPR tuning and recording management.
Updated 6 months ago (2026-03-11 02:57 UTC)
MIT

Frigate MCP Server

🌟 Features

📋 Prerequisites

🚀 Installation

1. Clone the repository

2. Create a virtual environment

3. Install dependencies

4. Configure environment

🔧 Configuration

Configuration Options

Example Configurations

🎯 Usage

1. STDIO Mode (Default)

2. SSE Mode (Server-Sent Events)

3. HTTP Mode (REST API)

Integrating with MCP Clients

Claude Desktop (STDIO Mode)

Testing the Connection

Running the MCP Server

Claude Desktop (STDIO Mode)

Web Clients (SSE Mode)

REST API (HTTP Mode)

🛠️ Available Tools

1. get_cameras()

2. get_events(camera, label, limit)

3. get_stats()

4. get_event_details(event_id)

5. get_snapshot(camera, timestamp)

6. get_recordings(camera, date)

7. get_config()

🏗️ Project Structure

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `get_cameras()`

2. `get_events(camera, label, limit)`

3. `get_stats()`

4. `get_event_details(event_id)`

5. `get_snapshot(camera, timestamp)`

6. `get_recordings(camera, date)`

7. `get_config()`