Skip to main content
Glama
Sign In
Atera Triage MCP

Atera Triage MCP

by MikeRiveira
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Active alerts

open_alerts
Read-only

Retrieve active Atera monitoring alerts, ordered by severity, to triage low disk space, failed backups, and offline machines.

Instructions

Active (unarchived) Atera monitoring alerts such as low disk space, failed backups or machines offline, most severe first and newest first within a severity. Each alert has its id, severity, title, machine, site and creation time. Returns the total count and the list.

Input Schema

NameRequiredDescriptionDefault
limitNoMost alerts to return, 1 to 100.
severityNoOnly return alerts of this severity. Leave empty for all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.0
    • addedInput schema / properties / limit / description
      Added value: +"Most alerts to return, 1 to 100."
    • addedInput schema / properties / limit / maximum
      Added value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / severity / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "Critical",
+      "Warning",
+      "Information"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / severity / description
      Added value: +"Only return alerts of this severity. Leave empty for all."
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the sort order (most severe first, newest within a severity) and the exact return payload (total count plus list with id, severity, title, machine, site, creation time). It stops short of stating that results are truncated by limit or what happens when there are no alerts.

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 tight sentences, front-loaded with scope and examples, then ordering, then return shape. Every clause carries information an agent needs; the field enumeration earns its place because no output schema exists.

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 no output schema, the description correctly compensates by naming the returned fields and total count. Filtering, limits and defaults are covered by a fully documented two-parameter schema, and both ordering dimensions are stated, so an agent has everything needed to call and interpret this read-only 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 description coverage is 100%, with both 'limit' (1-100, default 25) and 'severity' (enum plus null for all) fully documented in the schema. The description adds nothing parameter-specific; 'most severe first' loosely hints at severity ordering but not at how filtering behaves. 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?

States a specific resource (active/unarchived Atera monitoring alerts) with concrete examples (low disk space, failed backups, machines offline) and defines the exact ordering semantics. None of the siblings (morning_brief, triage_queue, get_ticket, site_health, technician_workload) is an alert-listing tool, so there is no ambiguity to resolve.

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?

Usage is only implied: the tool surfaces active alerts, which an agent can infer is for monitoring/incident triage. There is no explicit when-to-use statement, no mention of when to prefer a sibling like triage_queue or site_health, and no note that archived alerts are excluded except through the '(unarchived)' parenthetical.

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