Skip to main content
Glama
amittell

firewalla-mcp-server

by amittell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_alarm_trends

Read-only

Retrieve daily alarm counts for the last 30 days to identify security alert trends across all boxes or a specific group. Adjust the period to view overlapping days.

Instructions

Alarms generated per day, from GET /v2/trends/alarms: one point per day for the last 30 days, the last point being today so far. period (default 30d) returns the days that overlap it. The trends API takes no box, so it covers every box (or the group) even with FIREWALLA_BOX_ID set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupNoGet trends for a specific box group
periodNoReturn the days that overlap this period (default: 30d). The API has no finer resolution than a day, so 1h returns today so far and 24h returns yesterday and today30d

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.0
    • addedInput schema / properties / period
      Added value: +{
+  "default": "30d",
+  "description": "Return the days that overlap this period (default: 30d). The API has no finer resolution than a day, so 1h returns today so far and 24h returns yesterday and today",
+  "enum": [
+    "1h",
+    "24h",
+    "7d",
+    "30d"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Beyond readOnlyHint/openWorldHint, it discloses daily granularity, that the last point is today so far, period overlap behavior, and that the API ignores box scoping. This is valuable behavioral context, though the exact response shape is left unspecified.

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 focused sentences front-load the core result and endpoint, then add scoping and period behavior without redundancy. No filler.

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?

For a read-only two-parameter tool, the description covers endpoint, time window, granularity, period semantics, and box/group scoping. No output schema exists, but the daily-point framing gives enough shape to understand the return value.

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?

Both parameters are fully described in the schema (100% coverage), including enum values and period behavior. The description adds the note that the trends API takes no box, but this is more environmental context than parameter-level semantics; baseline 3 is appropriate.

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?

Clearly states it returns daily alarm counts from GET /v2/trends/alarms, with an explicit time window and granularity. The phrase 'Alarms generated per day' identifies the metric and resource, differentiating it from alarm search/detail tools, though it does not name a sibling.

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

Usage Guidelines4/5

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

Gives clear context: this is a trends API that covers every box (or group) even when FIREWALLA_BOX_ID is set, which signals when to use it over box-scoped alarm tools. It does not explicitly name alternatives or state when not to use it.

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

Deploy Server

Other Tools