Skip to main content
Glama

List Topology Links

cnc_list_topology_links
Read-onlyIdempotent

List network topology links with up/down status, utilization, and endpoint node/interface details to inspect L2 and L3 connectivity.

Instructions

List the links (edges) on the topology map with status and utilisation.

Read-only. Each link carries its type (display name, e.g. "L2 Ethernet" for LT_L2_ETHERNET, "L3 ISIS IPv4 L1", "L3 OSPF IPv4", "L3 BGP EPE IPv4"), status (Up/Degraded/Down), both endpoint node names/UUIDs and interface names, and per-direction utilisation labels such as "0.00015% (1.5Kbps/1Gbps)" with a HEALTHY/... severity. L2 links come from LLDP collection; L3 links need an SR-PCE provider (BGP-LS).

Paging is a row window: startRow = page * page_size, endRow = startRow + page_size. Past the end the platform returns totalCount with no rows (reported as an empty page, not an error). No filtering is available.

Args: page_size: rows per page (1-500). page: 0-based page number. response_format: markdown (default) or json.

Returns: str: Markdown "status linkType: srcNode:srcIf <-> dstNode:dstIf (util)" per link, or JSON: {"total": int, "count": int, "page": int, "page_size": int, "items": [{"uuid": str, "name": str, "linkType": "L2 Ethernet", "status": "Up", "sourceNode-name": str, "sourceNode-uuid": str, "sourceConnector-name": str, "targetNode-name": str, "targetNode-uuid": str, "targetConnector-name": str, "targetConnector-uto-label": str, "targetConnector-uto-severity": "HEALTHY", ...}], "has_more": bool, "next_page": int|null, ...} Each item is the element's uuid merged with its attributes. On failure: "Error: ". An HTTP 500 "Internal Server Error" from /v1/topology-service/... means the service rejected the request body (viewId/params) — deterministic, do NOT retry. (It is not the inventory's "NATS request failed" signal.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo0-based page number.
page_sizeNoRows per page (endRow - startRow).
response_formatNo'markdown' for human-readable output, 'json' for complete data.markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so 'Read-only' is redundant, but the description goes well beyond them: paging as a row window, past-the-end pages returning totalCount with no rows (not an error), no filtering available, and the deterministic HTTP 500 meaning the request body was rejected and must not be retried. That is substantive behavioral context, though the data-source caveat is the only precondition and auth/rate limits are untouched.

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 purpose is front-loaded and the Args section is tight, but the Returns block reproduces a full JSON item shape even though an output schema already exists, and the error-handling aside is a long parenthetical. Sizeable portions of the text do not earn their place against existing structured fields.

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 read-only paged list tool, the description covers paging edge cases, the no-filtering constraint, data-source prerequisites, and error semantics, and an output schema already carries the return shape. An agent has what it needs to call it correctly without guessing.

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%, so page, page_size and response_format are already documented. The description adds only the startRow/endRow paging formula, which is a modest gain over the schema's 'rows per page' wording; the 1-500 bound and markdown/json values merely restate 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?

States a specific verb+resource ('List the links (edges) on the topology map') and immediately scopes what each element is. Combined with its sibling names (list_topology_nodes, get_topology, get_topology_summary) an agent can tell it returns the edges rather than nodes or a summary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the resource name, and the description notes that link population depends on data sources (L2 via LLDP, L3 requires an SR-PCE provider/BGP-LS). But it never states when to pick this over cnc_list_topology_nodes or cnc_get_topology, nor any explicit exclusions.

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