Skip to main content
Glama

get_device_health

Read-onlyIdempotent

Get a combined health view for one ION element: operational state, software status, and optional interface status. Resolves by name or ID, rejecting ambiguous matches.

Instructions

Return a combined health view for one ION element.

element and site accept names or IDs. The tool resolves IDs safely, fetches element operational state, optionally software state/status, and can fan out to interface status. Interface fan-out is intentionally bounded.

Args: element: Element name, serial number, hardware ID, or exact controller ID. If it resolves to exactly one record, site can be omitted — the element's own site is used. Ambiguous names (e.g. a short substring matching many elements) fail instead of guessing; pass an exact name/ID or add site to narrow it. site: Site name or controller ID that should own element. Optional when element already resolves uniquely on its own. include_software: When true (default), also fetch software state/status for the element. A failure here is reported inline under partial_errors rather than failing the whole call. include_interfaces: When true, also fan out to per-interface status (bounded by interface_limit). Off by default because it adds one API call per interface. interface_limit: Max interfaces to fetch status for when include_interfaces is true. Ignored otherwise. Must be between 1 and the server's fan-out ceiling (default 100).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteNoSite name or controller ID that should own `element`. Optional when `element` already resolves uniquely on its own.
elementYesElement name, serial number, hardware ID, or exact controller ID. If it resolves to exactly one record, `site` can be omitted — the element's own site is used. Ambiguous names (e.g. a short substring matching many elements) fail instead of guessing; pass an exact name/ID or add `site` to narrow it.
interface_limitNoMax interfaces to fetch status for when `include_interfaces` is true. Ignored otherwise. Must be between 1 and the server's fan-out ceiling (default 100).
include_softwareNoWhen true (default), also fetch software state/status for the element. A failure here is reported inline under `partial_errors` rather than failing the whole call.
include_interfacesNoWhen true, also fan out to per-interface status (bounded by `interface_limit`). Off by default because it adds one API call per interface.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

The description adds significant behavioral context beyond the readOnly/idempotent annotations: element resolution accepts multiple identifier types, ambiguous names fail instead of guessing, software failures are reported under partial_errors, and interface fan-out is bounded by interface_limit. These are not visible in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear one-sentence purpose, but the subsequent Args block is a verbatim duplicate of the input schema's parameter descriptions. This redundancy makes it longer than necessary, though the structure is logical.

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?

The tool has an output schema and annotations, so the description needn't cover return values or safety. The description fully covers the resolution logic, optional invocation parameters, and error-handling behavior, making it complete for an agent to select and invoke correctly.

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 Args block in the description essentially mirrors the schema's parameter descriptions. The description adds no new meaning beyond the schema, though it does restate the resolution and partial_errors nuances already present in the schema.

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?

The description begins with 'Return a combined health view for one ION element,' a specific verb+resource statement. It clearly distinguishes from sibling get_* tools by emphasizing 'combined' and 'health view,' and the Args detail the optional software and interface fan-out.

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 clearly implies when to use this tool: when a combined health view is needed, with optional software and interface status. It provides context about the interface fan-out being off by default due to cost, but it does not explicitly name alternatives or exclusions like 'use get_interfaces for raw interface stats.'

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