Skip to main content
Glama
Sign In
Atera Triage MCP

Atera Triage MCP

by MikeRiveira
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Ranked ticket queue

triage_queue
Read-only

Rank open and pending Atera tickets by urgency with plain reasons, so you can decide what to work on next or review one site's queue.

Instructions

Open and pending tickets ranked by urgency, most urgent first, each with plain reasons such as "first-response SLA missed" or "user replied 40 min ago". Use this to decide what to work on next, or to see one store's queue.

    Levels: critical (waiting on IT over 24 h, or first-response SLA missed), high, normal,
    and waiting_on_user (IT replied last, so the ball is with the user). Duplicate tickets
    (same title from the same requester) are folded into one. Returns the total count and the
    ranked tickets; call get_ticket for a ticket's conversation.

Input Schema

NameRequiredDescriptionDefault
siteNoOnly include sites (Atera customers) whose name contains this text, case-insensitive, e.g. 'harbor' for 'Harbor Point Kia'. Leave empty for all sites.
limitNoMost tickets to return, 1 to 100.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.0
    • addedInput schema / properties / limit / description
      Added value: +"Most tickets to return, 1 to 100."
    • addedInput schema / properties / limit / maximum
      Added value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / site / description
      Added value: +"Only include sites (Atera customers) whose name contains this text, case-insensitive, e.g. 'harbor' for 'Harbor Point Kia'. Leave empty for all sites."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them with ranking semantics, the four level definitions, the explicit reasons tickets surface, and the deduplication rule ('same title from the same requester are folded into one'). It also discloses the return payload ('total count and the ranked tickets'), which is essential given there is no output schema.

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?

Front-loads the core purpose in the first sentence, then the level taxonomy, then the dedup rule and return value. The level enumeration is long but each definition earns its place by explaining ranking. Slight room to trim the illustrative reason examples.

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 still tells the agent what comes back (total count plus ranked tickets with reasons) and what the urgency levels mean. Combined with 100% schema coverage for the two optional parameters, an agent has everything needed to call this correctly on the first try.

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%, so the schema already explains both the site substring match and the 1-100 limit range. The description adds only a light gloss by framing site as 'one store's queue,' which is mild added meaning rather than new syntax or behavior. Baseline 3 is appropriate since the schema does the heavy lifting.

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 verb and resource in the first clause: 'Open and pending tickets ranked by urgency, most urgent first,' and even describes what each row contains ('plain reasons such as ...'). It is clearly separable from siblings like get_ticket and morning_brief, which do not return a ranked working queue.

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 concrete usage context ('decide what to work on next, or to see one store's queue') and explicitly routes to a sibling for a different need ('call get_ticket for a ticket's conversation'). It does not contrast against morning_brief, open_alerts, or site_health, so the alternative-selection guidance is clear but not exhaustive.

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