Skip to main content
Glama

get_routing

Read-onlyIdempotent

Retrieve BGP, OSPF, static routes, and routing policy objects for a single ION element, including peer statuses and prefixes, to verify routing health and configurations.

Instructions

Inspect BGP, OSPF, static routes, and routing policy objects for one ION.

Site and element accept names or IDs. bgp_status returns all peer states in one call where supported. bgp_prefixes resolves a specific BGP peer by peer ID/name/address and then retrieves reachable, advertised, or discovered prefixes. For bgp_status, include_prefixes=true enables composite behavior: reachable/filtered prefix counts are added per peer and Established peers receiving zero reachable prefixes are flagged. OSPF neighbor/prefix operations enumerate OSPF configs and fan out safely.

Args: operation: Which routing dataset to fetch. bgp_peers, bgp_config, ospf_config, static_routes, route_maps, prefix_lists, community_lists, and aspath_lists each return that object list directly. bgp_status returns peer session states with an established flag added. bgp_prefixes requires peer and returns one peer's prefixes (see prefix_kind). ospf_neighbors/ospf_prefixes fan out across every OSPF config found on the element. element: ION element name, serial number, hardware ID, or exact controller ID. Required for every operation. site: Site name or controller ID. Optional — inferred from element's inventory record when possible; only needed to disambiguate an element name that exists at more than one site. peer: BGP peer name, IP address, or exact ID. Required only for bgp_prefixes; resolved the same way as element (exact ID, then exact name/IP, then substring) — ambiguous or missing matches return a structured error with candidates instead of guessing. Ignored for every other operation. prefix_kind: For bgp_prefixes only: "reachable" (prefixes actually usable via this peer, the default), "advertised" (what we send the peer), or "discovered" (what the peer offered before filtering). Ignored for every other operation. include_prefixes: For bgp_status only. When true, also fetches per-peer reachable-prefix counts (one extra API call per peer, bounded by the server fan-out limit, default 100) and flags any Established peer with zero reachable prefixes via established_zero_prefixes — a fast way to spot a session that's up but not passing routes. Leave false for a quick status check. Ignored for every other operation. 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
peerNoBGP peer name, IP address, or exact ID. Required only for `bgp_prefixes`; resolved the same way as `element` (exact ID, then exact name/IP, then substring) — ambiguous or missing matches return a structured error with candidates instead of guessing. Ignored for every other operation.
siteNoSite name or controller ID. Optional — inferred from `element`'s inventory record when possible; only needed to disambiguate an element name that exists at more than one site.
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. Required for every operation.
operationYesWhich routing dataset to fetch. `bgp_peers`, `bgp_config`, `ospf_config`, `static_routes`, `route_maps`, `prefix_lists`, `community_lists`, and `aspath_lists` each return that object list directly. `bgp_status` returns peer session states with an `established` flag added. `bgp_prefixes` requires `peer` and returns one peer's prefixes (see `prefix_kind`). `ospf_neighbors`/`ospf_prefixes` fan out across every OSPF config found on the element.
prefix_kindNoFor `bgp_prefixes` only: `"reachable"` (prefixes actually usable via this peer, the default), `"advertised"` (what we send the peer), or `"discovered"` (what the peer offered before filtering). Ignored for every other operation.reachable
include_prefixesNoFor `bgp_status` only. When true, also fetches per-peer reachable-prefix counts (one extra API call per peer, bounded by the server fan-out limit, default 100) and flags any Established peer with zero reachable prefixes via `established_zero_prefixes` — a fast way to spot a session that's up but not passing routes. Leave false for a quick status check. Ignored for every other operation.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already declare read-only, open-world, and idempotent behavior. The description goes far beyond this by documenting resolution order (exact ID, then name/IP, then substring), structured error behavior with candidates, fan-out logic for OSPF neighbors/prefixes, and the extra API call per peer for include_prefixes with its fan-out limit. No contradictions with annotations.

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?

The description is front-loaded with a clear summary, then systematically covers all eight parameters and their interactions. Despite its length, every sentence serves a purpose—explaining operation-specific rules, defaults, and error handling. The structured Args block is easy to scan and free of fluff.

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 (12 operations, 8 parameters, multiple edge cases), the description is exceptionally complete. It covers all operations, parameter combinations, error behavior, pagination, server limits, and default values. The presence of an output schema eliminates the need to describe return formats, allowing the description to focus on invocation and behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing a baseline of 3. The description adds meaningful semantics above the schema: resolution rules for element and peer, ignored-parameter behavior per operation, the meaning of prefix_kind values, and the implication of include_prefixes with its performance tradeoff. This enriches an already well-described 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 opens with a specific verb and resource: 'Inspect BGP, OSPF, static routes, and routing policy objects for one ION.' This clearly distinguishes the tool from sibling tools like get_interfaces or get_topology by focusing exclusively on routing-related data for a single element.

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 detailed operational guidance, such as when to use include_prefixes ('Leave false for a quick status check') and which parameters are required for specific operations. It doesn't explicitly name alternative tools, but it clearly defines the scope of this tool and gives nuanced advice for its suboperations.

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