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., "@frigate-auth-mcp show me any person detections on the driveway camera today"
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.
An MCP server with authentication for Frigate NVR: lets an AI assistant (Claude Code, Claude Desktop, Hermes or any other MCP client) look at your cameras, events and reviews - and nothing more.
It logs in to Frigate's authenticated port as a user with the viewer role, so Frigate itself enforces what the
assistant may see. Tested with Frigate 0.17.x.
Related MCP server: MCP Frigate Optimizer
Python 3.11+ and uv. Nothing to install by hand: the MCP client starts the server from PyPI with
uvx frigate-auth-mcpThe latest code from GitHub runs with uvx --from git+https://github.com/adel-s/frigate-auth-mcp frigate-auth-mcp.
In Frigate, create a user for the assistant (Settings -> Users) with the role viewer. If the role lets you
limit cameras, give it only the cameras the assistant should see.
Add the server to your MCP client. For Claude Code, in .mcp.json:
{
"mcpServers": {
"frigate": {
"command": "uvx",
"args": ["frigate-auth-mcp"],
"env": {
"FRIGATE_URL": "https://frigate.example.com:8971",
"FRIGATE_USER": "assistant",
"FRIGATE_PASSWD": "${FRIGATE_PASSWD}"
}
}
}
}Keep the password out of the file: put it in the environment the client runs in.
Tool | What it returns | Frigate API |
| version, uptime, the cameras this user may see, per-camera fps |
|
| tracked-object events, filters by camera, label, time, GenAI description |
|
| one event in detail, with its GenAI description |
|
| snapshot of an event with the bounding box, optionally cropped |
|
| the current frame of a camera |
|
| review items as in the Frigate UI, last 7 days by default |
|
| alert and detection counts for the last 24 hours and per day |
|
Variable | Meaning |
| cameras allowed to return images, comma-separated; default all |
| password of the Frigate user, required (secret) |
| seconds per request, default |
| base URL of the authenticated port, default |
| Frigate username, required |
Talks to the authenticated port (8971 by default) only, never to the unauthenticated internal port 5000,
which gives full API access to anyone who can reach it.
Logs in as a Frigate user with the role viewer; the only non-GET call is POST /api/login.
No tool deletes, exports, edits the config or restarts anything.
The raw Frigate config is not exposed: it carries camera stream URLs with credentials.
Optional image filter FRIGATE_IMAGE_CAMERAS: only these cameras return images (snapshots, frames). This is the
second layer of protection, after the camera limit of the Frigate user's role; by default all cameras are
allowed. Use it when the MCP client sends images to a third-party model and some frames, such as indoor
cameras, must not leave your home.
The Frigate MCP server I found talks to port 5000 without authentication and exposes tools that delete events,
start exports, save the config or restart Frigate. Handing that to an AI model is more trust than a camera system
deserves. This server gives the assistant eyes, not hands.
Without after, Frigate's /api/review returns only the last 24 hours; list_reviews asks for the last 7 days
instead, so "what happened this week" gets a full answer.
list_events with has_description filters on the GenAI description, which the Frigate API cannot do itself.
uv run python -m unittest discover -s testsThe tests use unittest and a fake Frigate API on httpx.MockTransport, so they need no running Frigate. They
also check that no tool sends anything but GET, apart from the login.
GitHub Actions runs them on Python 3.11 to 3.14 on each push to master and dev/* branches.
If something doesn't work or you need a new feature feel free to open an issue and I'll fix it ASAP!
MIT, see LICENSE.
Snapshot of an event with its bounding box; crop=True zooms on the object.
| Name | Required | Description | Default |
|---|---|---|---|
| crop | No | ||
| event_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read operation and explains crop=True, but does not specify the return format (e.g., image, URL, or binary data), whether the bounding box is metadata or drawn on the image, or any permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the main output and the key crop behavior without any filler. Every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema and no annotations, the description still omits critical context such as the return type and how the bounding box is represented. An agent could call it but would not know what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It explains that crop=True zooms on the object, but does not explain the event_id parameter or its expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns a snapshot of an event, including its bounding box, and explains the crop zoom behavior. This is clearer than the name alone, but it does not explicitly distinguish the tool from siblings such as latest_frame or get_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like latest_frame or get_event. It also does not state any exclusions or prerequisites for calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Frigate version, uptime, the cameras this user may see and per-camera fps / detection fps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 does add real behavioral context by disclosing that camera results are permission-scoped ("the cameras this user may see"), but it never states that the call is read-only/non-mutating, whether it hits the Frigate API directly, or whether it is expensive or rate-limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; each item listed is a distinct piece of returned data. It is a noun-phrase fragment without a leading verb phrase ("Get..."), which slightly weakens scannability but costs no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description's enumeration of returned fields is the primary means of telling an agent what to expect, and it does that reasonably well. It stops short of describing the nesting/shape of the per-camera data, which is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is an empty object with no required fields, consistent with the description's framing as a no-argument status read.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates the concrete payload of a status call — version, uptime, permitted cameras, per-camera fps and detection fps — which is far more specific than the name alone. It lacks a verb and never explicitly contrasts with siblings, but the sibling set (list_events, get_event, event_snapshot, latest_frame, list_reviews, review_summary) is entirely event/review-oriented, so the distinction is obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
By listing server-level health data (version, uptime, fps), it implicitly signals a health-check/diagnostics use case rather than event inspection. However there is no explicit when-to-use statement, no prerequisites, and no named alternative for the adjacent task of pulling stream frames (latest_frame).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One event in detail, including the GenAI description when there is one.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must bear the full burden. It only describes the *content* of the response (the event and GenAI description) but offers zero insight into the operational behavior (e.g., latency, status codes, or data format).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and highly efficient. Both parts of the sentence directly contribute to defining the tool's scope and output characteristics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a data retrieval tool without an output schema. 'In detail' is too abstract, leaving the AI agent uncertain about the structure or nature of the detailed information being returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter (event_id) and zero schema coverage, the description doesn't add substantial meaning about the nature of the parameter itself beyond what the schema defines. This meets the minimum viable standard for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function is to retrieve 'One event in detail.' It sufficiently differentiates itself from siblings like list_events by specifying the singular nature of the retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied guidance by highlighting that it includes the GenAI description when available. However, it does not give explicit instructions on when *not* to use it, such as when only basic metadata is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The current frame of a camera.
| Name | Required | Description | Default |
|---|---|---|---|
| camera | Yes | ||
| height | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses almost nothing: not the return form (binary image, URL, base64), not whether the frame is cached or fetched live, not what happens for an offline camera. Only the implicit fact that it returns frame data is conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with no padding, so it is not verbose. But the terseness is under-specification rather than efficiency—there is nothing front-loaded beyond a bare resource label.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two undocumented parameters, no annotations, and no output schema, the description should at minimum say what comes back and how the resolution parameter affects it. An agent cannot reliably construct the call or handle the response from this text alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two parameters, so the description must compensate, and it does not: the expected format of `camera` (name vs id) and the meaning/effect of `height` (default 720, presumably a downscale for the returned image) are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a resource ("the current frame") tied to a camera, so an agent can infer it retrieves the latest image from a given camera. However, it is a noun phrase with no verb and gives no differentiation from siblings like event_snapshot, which plausibly also returns image data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, when to prefer event_snapshot or the event/review tools, or what preconditions apply (camera must exist and be online). Usage must be entirely inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tracked-object events, newest first. after/before: ISO 8601 or unix seconds. label e.g. person, cat, squirrel. has_description=True keeps only events with a GenAI description.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| label | No | ||
| limit | No | ||
| before | No | ||
| camera | No | ||
| has_description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the default ordering (newest first) and that filtering is inclusive-by-default, which are real behavioral facts, but it never states that this is a read-only listing, nor anything about pagination despite a limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very compact and front-loaded: the resource and ordering come first, then the parameter notes. Nothing is padded, though the telegraphic style costs a little readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need no explanation, and the filtering dimensions that matter for selecting results are covered at least at a surface level. The missing camera/limit detail is a parameter gap rather than a blocking incompleteness for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents the accepted time formats for after/before (ISO 8601 or unix seconds) and gives concrete label examples, but leaves camera and limit entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Tracked-object events, newest first" states the resource and the ordering explicitly, which is more than the name alone conveys. It distinguishes itself from get_event and list_reviews by scoping to the event list, though it never says so directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus get_event, list_reviews, or latest_frame, and no prerequisites or exclusions. The only implicit guidance comes from filter descriptions like has_description, which hint at narrowing rather than routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review items (what the Frigate UI shows), newest first. severity: alert or detection. after/before: ISO 8601 or unix seconds; after defaults to 7 days ago (Frigate itself returns only the last 24 hours when it is not set).
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| limit | No | ||
| before | No | ||
| camera | No | ||
| severity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose useful traits: newest-first ordering, the 7-day default for after, and Frigate's 24-hour fallback when after is unset. However, it omits limit and camera behavior and does not explicitly state read-only safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the resource and ordering, then gives severity and time-filter details without filler. Every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter read list with no annotations, it covers the most important time-window and severity semantics, and the output schema reduces the need to describe return values. It remains incomplete because limit and camera semantics and sibling-tool selection guidance are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all five parameters. It covers severity values and after/before formats and defaults, but limit and camera are left undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It identifies the resource clearly as review items, ties them to what the Frigate UI shows, and states newest-first ordering. It lacks an explicit verb like list and does not distinguish itself from siblings such as list_events or review_summary, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains filter semantics for severity and after/before, but gives no when-to-use or when-not-to-use guidance. It does not say when to choose list_reviews over list_events or review_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Counts of alerts and detections for the last 24 hours and per day for the last days days
(reviewed / not reviewed), as in the Frigate UI.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It discloses the aggregation behavior and time granularity, but omits read-only nature, auth/rate limits, error behavior, and exact return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single front-loaded sentence beginning with 'Counts of alerts and detections,' with no filler. The parenthetical reviewed/not-reviewed detail and Frigate UI reference are compact and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter summary tool, the description covers the core output categories and time windows. However, with no output schema and no annotations, it should more fully specify the response structure and safety/read-only context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, `days`, and the description explicitly defines it as the lookback span for per-day counts, compensating for 0% schema coverage. It does not clarify edge cases such as whether today is included or any bounds, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (alerts and detections) and the operation (counts/summary), with explicit time windows and a reviewed/not-reviewed split. It is clear enough to distinguish a summary aggregation from list_reviews or list_events, though it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is given; it does not say to prefer this over list_reviews or list_events when only counts are needed. 'As in the Frigate UI' hints at a dashboard-style summary but is not an actionable selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1event_snapshotfrigate_statusget_eventlatest_framelist_eventslist_reviewsreview_summaryScored across 7 tools
Each tool has a clearly distinct role: server status, event listing/detail/snapshot, live camera frame, review listing, and review summary. The event vs. review split and metadata vs. imagery split are explained well enough to prevent misselection.
Most tools follow a readable verb_noun pattern (list_events, get_event, list_reviews), but there are noun-first compounds (event_snapshot, review_summary, latest_frame) and a prefixed frigate_status. The deviations are minor and still predictable.
Seven tools is well-scoped for a Frigate monitoring server. Each tool covers a distinct operation without obvious redundancy or missing core capability at this surface size.
The set covers status, events, snapshots, live frames, and review summaries, which handles core monitoring workflows. However, it lacks event clip/recording retrieval and any operation to mark reviews as reviewed, despite surfacing reviewed/not-reviewed counts.
Read-only access to your Angelcam security cameras: live snapshots, recordings and camera health.
Read-only AI access to HAVN properties, leads, tasks, files, media, and analytics.
Connect AI assistants to explicitly paired computers, servers, and VMs for permitted remote actions.
Connect AI assistants to your approved computer for files, commands, browser and desktop tasks.
