Skip to main content
Glama

List Providers

cnc_list_providers
Read-onlyIdempotent

List and filter Crosswork providers by name or family to discover provider UUIDs and check reachability before managing topology or services.

Instructions

List the providers configured in Crosswork (SR-PCE, NSO, WAE, ...).

Read-only. Providers are the external systems CNC integrates with; the SR-PCE provider is what feeds the L3/SR-TE topology (via BGP-LS), and the NSO provider is used for service provisioning. Use this to discover provider UUIDs and check their reachability before touching devices, topology, or services; use cnc_get_provider for the full record.

Filters AND together. Only name and family are supported filters on this endpoint. Page with page/page_size (0-based).

Args: name: exact/wildcard name filter (case-insensitive). family: friendly family name (sr_pce, nso, wae, syslog_storage, alert, proxy, onc, accedian_proxy) or wire value. page_size, page: paging; has_more/next_page say whether to fetch another page. response_format: markdown (one line per provider: name, uuid, family, reachability, endpoints, credential profile) or json.

Returns: str: Markdown listing, or JSON: {"total": int|null, "count": int, "page": int, "page_size": int, "items": [{"uuid", "name", "family", "profile", "reachability_state", "connectivity_info": [...], "properties": {...}, ...}], "has_more": bool, "next_page": int|null, "collection_total": int|null, "offset": int, "next_offset": int|null} total is the number of providers matching the filter (absent / null when Crosswork omits it, which it does for zero matches); collection_total is the size of the whole provider collection. On failure: "Error: " (unknown family value -> the list of accepted values; 500 "NATS request failed" -> malformed request rather than an outage).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoProvider name filter: exact match, case-insensitive, '*' is a wildcard (e.g. 'cml-pce' or '*pce*'). No substring match without '*'.
pageNo0-based page number (e.g. 0).
familyNoProvider family filter, one of: accedian_proxy, alert, nso, onc, proxy, sr_pce, syslog_storage, wae (e.g. 'sr_pce'); wire values such as 'ROBOT_PROVIDER_SR_PCE' are accepted too.
page_sizeNoProviders per page (e.g. 20).
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.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive/openWorld), and 'Read-only' restates them. The description does add genuinely non-annotated behavior: response_format output contents, 0-based paging with has_more/next_page, the null/absent semantics of total vs collection_total, and concrete error semantics (unknown family returns accepted values; 500 NATS request failed means malformed request, not an outage).

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?

Front-loaded and organized with clear sections, but verbose: the Args block largely restates the 100%-covered schema and the Returns block reproduces the full JSON shape even though an output schema exists. The one valuable non-redundant detail is the total-vs-collection_total distinction on zero matches.

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 list tool it covers everything an agent needs: what it returns, how to page, how filters combine, the sibling to use for detail, and how to interpret failure messages. Missing values for providers/reachability are explained via the field semantics.

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 coverage is 100%, so the baseline is 3; the description still adds cross-parameter meaning not in the schema, notably that filters AND together, that only name and family are honored on this endpoint, the accepted family values, and what each response_format yields. The name wildcard rule is repeated from the schema rather than extended.

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?

Names a specific verb and resource ('List the providers configured in Crosswork'), enumerates the concrete provider types (SR-PCE, NSO, WAE), and explains what a provider is and which one feeds the topology. It is trivially distinguishable from cnc_get_provider, which it names.

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 states when to use it ('discover provider UUIDs and check their reachability before touching devices, topology, or services') and names the alternative for the other case ('use cnc_get_provider for the full record'). It also states the filter composition rule (filters AND together) and which filters this endpoint supports.

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