Skip to main content
Glama

List Topology Nodes

cnc_list_topology_nodes
Read-onlyIdempotent

List topology nodes as a sorted, paged table to inspect per-node attributes like management IP, TE router ID, reachability, and device family; read-only.

Instructions

List the nodes on the topology map as a sorted, paged table.

Read-only. Topology nodes are the devices CNC has placed on the map (fed by inventory + SR-PCE); their UUIDs match the inventory node UUIDs. Use this for per-node attributes (management IP, TE router-id, reachability, family); use cnc_get_topology for adjacency.

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 on this endpoint — filter client-side or use the inventory tools. The platform silently accepts an unknown sort column (undefined order), so sort_by is validated here first.

Args: page_size: rows per page (1-500). page: 0-based page number. sort_by: column to sort on (see the parameter description). sort_ascending: sort direction. response_format: markdown (default) or json.

Returns: str: Markdown listing, or JSON: {"total": int, "count": int, "page": int, "page_size": int, "items": [{"uuid": str, "name": str, "nodeIp": str, "teRouterId": str, "reachabilityState": "CONN_STATE_REACHABLE"|..., "productType": str, "deviceFamily": str, "lastUpdateTime": str, ...}], "has_more": bool, "next_page": int|null, ...} Each item is the element's uuid merged with its attributes. On failure: "Error: " (unknown sort column -> "Error: Unknown sort column ..."). 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.
sort_byNoColumn to sort on: 'name' (default), 'nodeIp', 'lastUpdateTime' (all three verified live), 'teRouterId', 'reachabilityState', 'productType' or 'deviceFamily'.name
page_sizeNoRows per page (endRow - startRow).
sort_ascendingNoSort ascending (true, default) or descending.
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

A4.8/5.0
Behavior5/5

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

Despite annotations already declaring read-only/idempotent behavior, the description adds substantial behavioral context: paging is a row window, past-the-end returns totalCount with no rows rather than an error, unknown sort columns are silently accepted by the platform but validated here, and an HTTP 500 means a deterministic rejection that should not be retried.

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 structured with Args and Returns sections and front-loads the primary purpose and sibling routing. It is detailed but most sentences carry operational value; some return-format detail is redundant given the output schema.

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, filterless list tool with annotations and an output schema, the description covers the key edge cases: paging behavior, lack of server-side filtering, sort validation, and non-retryable HTTP 500 failures. Nothing material is missing for correct invocation.

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%, so the baseline would be 3. The description adds paging semantics beyond the schema, including the formulas startRow = page * page_size and endRow = startRow + page_size, and notes that sort_by is locally validated against unknown columns.

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 and resource: 'List the nodes on the topology map as a sorted, paged table.' It also distinguishes the tool from its sibling cnc_get_topology, which is for adjacency rather than per-node attributes.

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

Usage Guidelines5/5

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

Explicitly says to use this for per-node attributes and directs adjacency queries to cnc_get_topology. It also states there is no filtering on this endpoint and recommends client-side filtering or inventory tools as alternatives.

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