Skip to main content
Glama

get_monitoring

Read-onlyIdempotent

Retrieve Prisma SD-WAN operational monitoring for incidents, flows, link/probe metrics, and AIOps insights. Filter by site, time range, severity, or raw mode to analyze network health and anomalies.

Instructions

Unified operational monitoring for incidents, flows, metrics, and AIOps.

Events/alarms carry an important warning: an unwindowed call only sees the most recent records and may miss an older incident. Use start_time and end_time for incident analysis. Flow digest mode summarizes application, path, action, and top talkers; raw=true returns records. Link/probe metrics are recorded telemetry, not an active ping test.

Args: operation: Which monitoring dataset. events/alarms query the incident log (see start_time/end_time below — they behave differently here than for the other operations). flows returns a summarized digest by default (raw=true for individual flow rows) and requires site. link_metrics/ probe_metrics return recorded telemetry (not a live probe) and require site. aiops_health, aiops_anomaly, aiops_forecast, aiops_aggregates, system_metrics, qos_metrics, and bandwidth_stats are tenant-wide AIOps datasets that ignore site, element, hours, start_time, and end_time entirely. site: Site name or controller ID. Required for flows, link_metrics, and probe_metrics; an optional filter for events/alarms; ignored by every aiops_*/system_metrics/ qos_metrics/bandwidth_stats operation. element: ION element name or ID. Optional filter with the same scope as site; ignored wherever site is ignored. hours: Lookback window in hours (max 168) ending now. Used only when start_time/end_time are both omitted, and only for flows, link_metrics, probe_metrics. Has no effect on events/alarms or any aiops_* operation. start_time: ISO 8601 timestamp. For flows/link_metrics/ probe_metrics this must be paired with end_time (supply both or neither) and replaces hours. For events/alarms it is an independent, optional lower bound — you may pass it alone to mean "since this time". Leaving both start_time and end_time unset on events/alarms returns only the most recent records and can silently miss an older incident. end_time: ISO 8601 timestamp — see start_time for the pairing rules, which differ by operation. severity: Comma-separated severity filter for events/alarms (e.g. "critical,major"). Ignored for every other operation. raw: When true, skip summarization and return raw records instead: individual flow rows for flows (capped at 500), or per-datapoint metric series for link_metrics/probe_metrics instead of the path/probe-pivoted view. Ignored for every other operation. limit: Max items to return in this page for list-shaped results (events, alarms, raw flows, probe_metrics). Capped at 100 for events/alarms. Ignored for single-object results (flow digest, link_metrics) — because link_metrics cannot be paginated, a wide window can exceed the server's response byte budget, in which case the whole payload is replaced by an identifying stub plus "warning": "item exceeded response budget...". That warning means the data was dropped, not that no data exists: retry with a smaller hours (a multi-day window is the usual cause). cursor: Opaque pagination token copied from a previous response's next_cursor. Only meaningful where limit is. app: Application ID/name filter — flows only. Ignored elsewhere. path_id: Path ID filter — flows only. Ignored elsewhere. waninterface_id: WAN interface ID filter — flows only. Ignored elsewhere.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoApplication ID/name filter — `flows` only. Ignored elsewhere.
rawNoWhen true, skip summarization and return raw records instead: individual flow rows for `flows` (capped at 500), or per-datapoint metric series for `link_metrics`/`probe_metrics` instead of the path/probe-pivoted view. Ignored for every other operation.
siteNoSite name or controller ID. Required for `flows`, `link_metrics`, and `probe_metrics`; an optional filter for `events`/`alarms`; ignored by every `aiops_*`/`system_metrics`/ `qos_metrics`/`bandwidth_stats` operation.
hoursNoLookback window in hours (max 168) ending now. Used only when `start_time`/`end_time` are both omitted, and only for `flows`, `link_metrics`, `probe_metrics`. Has no effect on `events`/`alarms` or any `aiops_*` operation.
limitNoMax items to return in this page for list-shaped results (`events`, `alarms`, raw `flows`, `probe_metrics`). Capped at 100 for `events`/`alarms`. Ignored for single-object results (flow digest, `link_metrics`) — because `link_metrics` cannot be paginated, a wide window can exceed the server's response byte budget, in which case the whole payload is replaced by an identifying stub plus `"warning": "item exceeded response budget..."`. That warning means the data was dropped, not that no data exists: retry with a smaller `hours` (a multi-day window is the usual cause).
cursorNoOpaque pagination token copied from a previous response's `next_cursor`. Only meaningful where `limit` is.
elementNoION element name or ID. Optional filter with the same scope as `site`; ignored wherever `site` is ignored.
path_idNoPath ID filter — `flows` only. Ignored elsewhere.
end_timeNoISO 8601 timestamp — see `start_time` for the pairing rules, which differ by operation.
severityNoComma-separated severity filter for `events`/`alarms` (e.g. `"critical,major"`). Ignored for every other operation.
operationYesWhich monitoring dataset. `events`/`alarms` query the incident log (see `start_time`/`end_time` below — they behave differently here than for the other operations). `flows` returns a summarized digest by default (`raw=true` for individual flow rows) and requires `site`. `link_metrics`/ `probe_metrics` return recorded telemetry (not a live probe) and require `site`. `aiops_health`, `aiops_anomaly`, `aiops_forecast`, `aiops_aggregates`, `system_metrics`, `qos_metrics`, and `bandwidth_stats` are tenant-wide AIOps datasets that ignore `site`, `element`, `hours`, `start_time`, and `end_time` entirely.
start_timeNoISO 8601 timestamp. For `flows`/`link_metrics`/ `probe_metrics` this must be paired with `end_time` (supply both or neither) and replaces `hours`. For `events`/`alarms` it is an independent, optional lower bound — you may pass it alone to mean "since this time". Leaving both `start_time` and `end_time` unset on `events`/`alarms` returns only the most recent records and can silently miss an older incident.
waninterface_idNoWAN interface ID filter — `flows` only. Ignored elsewhere.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

The description adds substantial behavioral caveats beyond the annotations: unwindowed events/alarms can silently miss older incidents, link/probe metrics are recorded telemetry not active probes, raw flows are capped at 500, and link_metrics responses may be replaced by a warning stub. These are critical operational truths essential for correct interpretation.

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?

The description is long, but the tool is complex with 13 parameters and 12 operation types. It is well-structured with a front-loaded summary, a prominent early warning, and organized Args; however, it repeats much of the schema parameter documentation, keeping it from a perfect conciseness score.

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?

For a tool with this complexity, the description covers all essential operational constraints: parameter scopes, ignored-parameter rules, required pairings (start_time/end_time), pagination, response-budget failures, and dataset-specific behavior. The presence of an output schema further covers return shapes, so no major gaps remain.

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% and the schema already contains equally detailed parameter explanations for operation, site, start_time, end_time, limit, and raw. The description's Args section largely duplicates these descriptions, so it adds no significant meaning beyond the schema, meeting the baseline but not exceeding it.

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?

First sentence clearly defines the tool as 'Unified operational monitoring for incidents, flows, metrics, and AIOps,' which names the resource and scope and distinguishes it from sibling get_* tools that target specific domains. The detailed operation enumeration reinforces the unified monitoring purpose.

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?

The description does not name sibling tools or provide explicit when-to-use versus get_routing/get_topology, but the 'Unified operational monitoring' framing plus operation-specific requirements (e.g., site required for flows/link_metrics/probe_metrics, events/alarms need start_time/end_time for thorough incident analysis) give clear application context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iamdheerajdubey/prisma-sdwan-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server