Provides search and exploration of Cisco IOS XE YANG models, enabling discovery of gNMI paths and retrieval of node details with keys and children.
Provides search and exploration of Nokia SR OS YANG models, enabling discovery of gNMI paths by subject and retrieval of node details with keys and children.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@yangmap-mcp find the gNMI path for interface statistics on nokia_sros"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Which gNMI path carries which information, on which vendor, in which OS version.
A language model given read-only gNMI access doesn't know where to look. It knows CLI syntax by heart and invents plausible YANG paths that don't exist. yangmap gives it the map — built from the YANG published by the vendor, not from a hand-written list.
$ yangmap chercher "active and inactive routes" nokia_sros --version 24.3.R3
nokia_sros 24.3.3 (exact)
[ 31.44] /state/router[router-name=?]/route-table/unicast/ipv4/statistics/aggregate/available-routes
leaf/uint32 — Count of routes of a routing protocol, both active in the FIB and inactive in the RIB.It connects to no equipment. No credentials, no inventory, no socket. It's a documentation server, not a collection server — and that's what gives it a zero security surface.
The caller discovers the equipment's version (gNMI Capabilities) and passes
it as a parameter. yangmap stays offline and unprivileged.
Related MCP server: VyOS MCP Server
Guarantee | Mechanism | Test |
No equipment contact | No server module imports a network library |
|
No access to secrets | No module imports |
|
The download path is unreachable from a tool |
|
|
No silent fallback between vendors | Unknown platform ⇒ error |
|
A version mismatch is always reported | Every response carries the bundle actually served |
|
These tests were deliberately broken before being fixed. One of them
protected nothing: from yangmap import bundles passed, because the AST
extractor only picked up the module, never the imported name.
python3 -m venv .venv
.venv/bin/pip install -e ".[dev]"# 1. Download the vendor's YANG — the ONLY command that touches the network
yangmap fetch nokia_sros 24.3.R3
# 2. Build the index — offline from here on
yangmap build nokia_sros
# 3. Search
yangmap chercher "SFP transceiver" nokia_sros
yangmap detail "/state/port[port-id=?]/transceiver" nokia_sros
yangmap versionsBundles and indexes live under ~/.yangmap and are never version-controlled:
they regenerate from a single command.
yangmap-mcpThree tools, and not one more:
Tool | Returns |
| Ranked paths, with type and vendor description |
| The node, the keys it requires, and its immediate children |
| Does this path run, and what will it return — before contacting anything |
The second lets the model descend the tree without guessing. The third answers the question that follows.
yang_valider — the three failures that look identicalA failing path returns in three ways, and once returned they are indistinguishable:
What happened | What the model receives | What it concludes |
The path does not exist | An empty response | "The feature is not configured" |
A key was left as a template ( | An empty response | "The feature is not configured" |
The subtree is enormous | A truncated response | It draws conclusions from amputated data |
The first two are false facts stated with confidence; the third is worse because it is invisible. yang_valider distinguishes them offline, before any contact, and returns an explicit reason instead of a blank void.
$ yangmap valider '/configure/router[router-name=Base]/bgp/group[group-name=transit]/export-policy' nokia_sros
[KO] inexistant
unknown segment: 'export-policy' under /configure/router[]/bgp/group[].
Possible children: export, ebgp-default-reject-policy, import.
$ yangmap valider '/state/router[router-name=Base]/interface[interface-name=*]' nokia_sros
[!!] volumineux
518 nodes under this path, ~3470 characters per instance.The payload threshold is calibrated, not chosen arbitrarily: netlive's interfaces collector targeted this container and returned 17,583 characters for 5 interfaces, compared to 573 when narrowed to the useful leaves. Hence ~6.7 characters per descendant and per instance — the estimator comes within 1% of this real measurement.
arbre="etat" (default) is operational state, what a diagnostic Get queries. arbre="conf" is the configuration tree.
It was previously missing, and that absence had a cost: on netlab, four consecutive searches for bgp group export-policy returned nothing — not because the path is missing from the model, but because no /configure path was indexed. With arbre="conf", the correct path ranks first:
$ yangmap chercher "bgp group export policy" nokia_sros --arbre conf
[ 33.44] /configure/router[router-name=?]/bgp/group[group-name=?]/export/policy
leaf-list/union — BGP export policy nameThe two trees never mix in the same ranking: every state node has a configuration twin that would compete for the exact same words. Measured: the Nokia golden set stays at 11/11 after doubling the index.
Platform | YANG source | Indexed models | Paths | Descriptions |
| nokia/7x50_YangModels, tag per revision |
| 115,557 | 98% |
| YangModels/yang, |
| 12,123 | 97% |
| OpenConfig | 9,924 | 100% |
The exact version isn't always published — Nokia goes down to the patch, Cisco and Arista stop at the train. Falling back is therefore the normal case, and it is reported in every response:
{"bundle_servi": "17.3.1", "version_demandee": "17.3.4a", "ecart": "meme_train",
"avertissement": "Version 17.3.4a not published by the vendor: bundle 17.3.1 served…"}This is the only genuinely hard part, and it's defined by its measurement: a golden set of real questions, metric "is the expected path in the top five". 21 questions, three platforms, 100%.
python goldenset/mesurer.py # measure
python goldenset/mesurer.py --ablation # does each signal earn its place?Four signals, all proven useful by ablation:
Signal neutralized | Rate | Delta |
BM25 on descriptions | 76% | −24% |
BM25 on path segments | 86% | −14% |
Exact segment match | 90% | −10% |
Depth penalty | 95% | −5% |
Two signals were tried and then dropped for lack of measurable effect: boosting leaves, and term coverage. A signal that doesn't move a single golden-set entry doesn't stay in the code.
A naive substring search returns, across all three vendors:
Question | Top raw result |
"transceiver" (Nokia) |
|
"routing table" (Nokia) |
|
"routing table" (Arista) |
|
The correct data is in the index every time. This is a ranking defect, never a data defect.
.venv/bin/python -m pytest -m "not lab" # 101 tests, no network or hardware
.venv/bin/python -m pytest -m lab # 9 tests against a real containerlabTrouve les chemins gNMI qui portent une information donnée, classés du plus pertinent au moins pertinent. Ce que l'on cherche, en langage naturel : « routes actives et inactives », « transceiver SFP », « adjacences ISIS ». Le français est accepté. Vendeur : nokia_sros, cisco_iosxe, arista_eos. Version d'OS de l'équipement, telle que rendue par gNMI Capabilities (ex. 24.3.R3). Facultative — sans elle, la version la plus récente installée est servie, et l'approximation est déclarée. Rend pour chacun : le chemin prêt à interroger, le genre de nœud, le type de donnée et la description du vendeur.
| Name | Required | Description | Default |
|---|---|---|---|
| sujet | Yes | ||
| limite | No | ||
| version | No | ||
| plateforme | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses relevance ranking, French language acceptance, version fallback behavior (most recent installed version used and approximation declared), and the return structure (path, node kind, data type, vendor description). This goes beyond a basic operation statement, though it does not mention potential side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a moderately long paragraph but every sentence adds value: purpose, use examples, language, vendors, version behavior, and return items. It is front-loaded with the primary function and avoids tautology. It could be slightly more concise, but the length is justified by the detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with moderate complexity, the description covers purpose, inputs, outputs, and fallback behavior. The mention of the return items compensates for the lack of an explicit output schema. The only gap is the omission of the 'limite' parameter and potential explicit differentiation from the sibling tool, but overall it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'sujet' as a natural-language query, 'plateforme' via vendor examples (nokia_sros, cisco_iosxe, arista_eos), and 'version' with an example ('24.3.R3') and optionality. However, it entirely omits the 'limite' parameter and does not specify exact value formats for 'plateforme', leaving a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds gNMI paths carrying given information and ranks them by relevance ('Trouve les chemins gNMI qui portent une information donnée, classés du plus pertinent au moins pertinent'). It identifies a specific verb, resource, and behavior, making the purpose clear. However, it does not explicitly distinguish itself from the sibling tool 'yang_detail', missing the opportunity for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains natural-language input with examples ('routes actives et inactives', 'transceiver SFP'), mentions supported vendors, and details the optional 'version' parameter with fallback behavior. It does not explicitly exclude scenarios or recommend the sibling tool, but the context is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Détaille un chemin rendu par yang_chercher : sa description, les clés à renseigner, et ses ENFANTS IMMÉDIATS — pour descendre dans l'arbre sans deviner. Vendeur : nokia_sros, cisco_iosxe, arista_eos. Version d'OS de l'équipement, telle que rendue par gNMI Capabilities (ex. 24.3.R3). Facultative — sans elle, la version la plus récente installée est servie, et l'approximation est déclarée.
| Name | Required | Description | Default |
|---|---|---|---|
| chemin | Yes | ||
| version | No | ||
| plateforme | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the optional `version` behavior (if omitted, the latest installed version is used and the approximation is declared) and lists allowed vendors. However, it does not explicitly state that the tool is read-only or describe side effects, which would strengthen transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly verbose but every sentence adds value, including parameter details and behavioral notes. The structure is a bit run-on, mixing purpose with param descriptions, but it remains focused and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter semantics, and a key behavioral nuance (version approximation). Since an output schema exists, return values need not be described. It could mention error cases or more explicitly connect to the sibling tool, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains `chemin` as a path from `yang_chercher`, `plateforme` by listing supported vendors, and `version` as optional with clear behavioral consequences. All three parameters are semantically covered, far exceeding the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Détaille un chemin rendu par `yang_chercher`' and lists what it provides (description, keys, immediate children). It explicitly differentiates from the sibling tool by focusing on detailing a path already found, not searching for one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage as a follow-up to `yang_chercher` by noting the input path comes from that tool. The phrase 'pour descendre dans l'arbre sans deviner' gives clear context for when to use it, though it does not explicitly state when not to use it or mention any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one searches for paths based on natural language, the other details a specific path by describing its keys and children. There is no ambiguity between them.
Both tools share the 'yang_' prefix, but one uses a verb ('chercher') and the other a noun ('detail'). This is a minor inconsistency, but the pattern is still predictable and readable.
With only two tools, the server feels thin, but the scope is narrow and well-defined: search and detailed exploration of YANG paths. It is borderline but not excessive.
The pair covers the core workflow of finding and exploring YANG paths. A minor gap is the lack of a direct way to list all paths or vendors, but the search functionality effectively compensates.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted 3GPP MCP server for Rel-15–20 TS/TR search. Index stays current.
Public, read-only MCP server for FarmNeural company facts, packages, and capabilities.
A server to provide information about EOxElements custom elements for coding agents.
Read-only search and discovery for the international llms.txt directory maintained by llmsmap.me.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/FODYZ/yangmap'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
