Skip to main content
Glama

get_device_diagnostics

Read-onlyIdempotent

Get Prisma SD-WAN device diagnostics without raw API IDs: LLDP neighbors, MAC table, port/VLAN mappings, BFD peers, and application probe config.

Instructions

Retrieve common device-side diagnostic state without requiring raw API IDs.

Covers LLDP neighbors, MAC table, switch port/VLAN mappings, BFD peers, and application-probe configuration. Site is inferred from the element whenever the element inventory record provides site_id.

Args: operation: Which diagnostic to fetch. lldp_neighbors and mac_table need only element. bfd_peers, port_to_vlan, vlan_to_port, and application_probe also need a resolvable site (explicit, or inferred from the element's inventory record) — if neither is available, these four return an error rather than guessing. port_to_vlan/vlan_to_port additionally require a switch-capable element model; on other models the controller rejects the read with a "does not support switch configuration" message, which means wrong device type, not a failed lookup — don't retry it against the same element. element: ION element name, serial number, hardware ID, or exact controller ID. Always required. site: Site name or controller ID. Optional for lldp_neighbors/ mac_table; required (explicit or inferable from element) for bfd_peers, port_to_vlan, vlan_to_port, and application_probe. cursor: Opaque pagination token copied from a previous response's next_cursor. Omit on the first call. limit: Max items to return in this page. Omit to use the server default page size (50; max 200).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteNoSite name or controller ID. Optional for `lldp_neighbors`/ `mac_table`; required (explicit or inferable from `element`) for `bfd_peers`, `port_to_vlan`, `vlan_to_port`, and `application_probe`.
limitNoMax items to return in this page. Omit to use the server default page size (50; max 200).
cursorNoOpaque pagination token copied from a previous response's `next_cursor`. Omit on the first call.
elementYesION element name, serial number, hardware ID, or exact controller ID. Always required.
operationYesWhich diagnostic to fetch. `lldp_neighbors` and `mac_table` need only `element`. `bfd_peers`, `port_to_vlan`, `vlan_to_port`, and `application_probe` also need a resolvable `site` (explicit, or inferred from the element's inventory record) — if neither is available, these four return an error rather than guessing. `port_to_vlan`/`vlan_to_port` additionally require a switch-capable element model; on other models the controller rejects the read with a "does not support switch configuration" message, which means wrong device type, not a failed lookup — don't retry it against the same element.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already indicate a safe, read-only, idempotent operation, but the description adds significant behavioral nuance: it explains that missing site info leads to an error 'rather than guessing', that `port_to_vlan`/`vlan_to_port` on non-switch models yield a 'does not support switch configuration' message (indicating wrong device type, not a failed lookup), and advises against retrying. It also documents pagination cursor semantics. This goes well beyond the annotation basics.

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 well-structured: a one-line summary followed by a clear list of parameters with inline explanations. It is somewhat lengthy, but every sentence conveys necessary behavioral or dependency details. It earns a high score for being appropriately front-loaded and free of fluff, though a more compact presentation could slightly improve it.

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?

Given the tool's complexity (multiple operations with different requirements, pagination, site inference), the description is remarkably complete. It explains operation-specific prerequisites, error semantics, and pagination behavior. An output schema exists, so not detailing return values is acceptable. The description leaves no obvious gaps for an agent to misuse the 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?

The input schema already provides 100% parameter coverage with detailed descriptions for `element`, `site`, `cursor`, `limit`, and `operation`. The tool description's Args section largely mirrors the schema descriptions, adding no additional meaning beyond what the schema already conveys. Therefore the schema does the heavy lifting, and the description adds no new parameter-level insight.

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 opens with a specific verb ('Retrieve') and a clear resource ('common device-side diagnostic state'), followed by a concrete list of diagnostics (LLDP neighbors, MAC table, port/VLAN mappings, BFD peers, application-probe configuration). This clearly differentiates it from sibling tools like get_routing or get_interfaces by focusing on device diagnostics rather than routing or interface data.

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 provides clear operation-level guidance: which operations require only `element`, which require a resolvable `site`, and which require switch-capable models. It also explains the error behavior for unsupported device types. However, it does not explicitly contrast this tool with alternatives (e.g., 'use get_routing for routing state'), so it falls short of a 5.

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