Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
aiskillstore avatar

Routeros Command Tree

  • 1 installs
  • 404 repo stars
  • Updated August 5, 2026
  • aiskillstore/marketplace

routeros-command-tree is a skill for introspecting the MikroTik RouterOS command hierarchy through the /console/inspect REST endpoint.

About

routeros-command-tree is a skill for RouterOS command-tree introspection via the /console/inspect REST endpoint. It explains the four node types, child/syntax request formats, recursive tree traversal, and CLI-to-REST verb mapping used by tools like restraml and rosetta. A developer uses it when building tools that parse RouterOS commands or generate API schemas from RouterOS.

  • Traverse the RouterOS command tree via /console/inspect
  • Map CLI commands to REST verbs for schema generation
  • Flags dangerous subtrees that crash the REST server

Routeros Command Tree by the numbers

  • 1 all-time installs (skills.sh)
  • Ranked #933 of 1,039 Cloud & Infrastructure skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
At a glance

routeros-command-tree capabilities & compatibility

Capabilities
api introspection · schema generation · tree traversal
Use cases
api development
From the docs

What routeros-command-tree says it does

The `/console/inspect` REST endpoint lets you **programmatically explore the entire tree**
SKILL.md
These path segments **crash the RouterOS REST server** when their `arg` nodes are queried for syntax via `/console/inspect`.
SKILL.md
npx skills add https://github.com/aiskillstore/marketplace --skill routeros-command-tree

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars404
Last updatedAugust 5, 2026
Repositoryaiskillstore/marketplace

What it does

Programmatically explore the RouterOS command tree and generate API schemas via /console/inspect.

Who is it for?

Building tools that parse RouterOS commands or generate OpenAPI/RAML schemas from RouterOS

Skip if: General Linux networking or RouterOS v6

When should I use this skill?

Traversing the RouterOS command tree, using /console/inspect, or mapping CLI commands to REST verbs

What you get

A programmatically walked command tree with descriptions and CLI-to-REST verb mappings.

  • Recursive tree-walk function
  • CLI-to-REST verb map

By the numbers

  • 4 command-tree node types
  • 6 dangerous path segments to skip

Files

SKILL.mdMarkdownGitHub ↗

RouterOS Command Tree & /console/inspect

Overview

RouterOS organizes all configuration and commands in a hierarchical tree. Every path in the CLI (like /ip/address/add) corresponds to a node in this tree. The /console/inspect REST endpoint lets you programmatically explore the entire tree — this is how tools like restraml (RAML/OpenAPI schema generator) and rosetta (MCP command lookup) build their databases.

The Command Tree Structure

RouterOS's command hierarchy has four node types:

Node TypeMeaningExample
dirDirectory — contains child paths/ip, /system
pathPath — a navigable level (often has commands)/ip/address, /interface/bridge
cmdCommand — an executable actionadd, set, print, remove, get, export
argArgument — a parameter to a commandaddress=, interface=, disabled=

Tree Example

/ (root dir)
├── ip/ (dir)
│   ├── address/ (path)
│   │   ├── add (cmd)
│   │   │   ├── address (arg) — "IP address"
│   │   │   ├── interface (arg) — "Interface name"
│   │   │   └── disabled (arg) — "yes | no"
│   │   ├── set (cmd)
│   │   ├── remove (cmd)
│   │   ├── get (cmd)
│   │   ├── print (cmd)
│   │   └── export (cmd)
│   ├── route/ (path)
│   │   └── ...
│   └── dns/ (path)
│       ├── set (cmd)
│       ├── cache/ (path)
│       │   ├── print (cmd)
│       │   └── flush (cmd)
│       └── ...
├── interface/ (dir)
│   └── ...
├── system/ (dir)
│   └── ...
└── ...

/console/inspect API

Endpoint

POST /rest/console/inspect

Requires basic authentication. Available on all RouterOS 7.x versions.

Request Types

RequestPurposeReturns
childList children of a pathArray of {type: "child", name, "node-type"}
syntaxGet help text for a nodeArray of {type: "syntax", text}
highlightSyntax highlighting dataTokenized output (rarely used)
completionTab-completion suggestionsCompletion candidates

Listing Children

// List children of /ip
const children = await fetch(`${base}/console/inspect`, {
  method: "POST",
  headers: { ...authHeaders, "Content-Type": "application/json" },
  body: JSON.stringify({
    request: "child",
    path: "ip",
  }),
}).then(r => r.json());

// Response:
// [
//   { "type": "child", "name": "address",    "node-type": "path" },
//   { "type": "child", "name": "arp",        "node-type": "path" },
//   { "type": "child", "name": "cloud",      "node-type": "path" },
//   { "type": "child", "name": "dhcp-client", "node-type": "path" },
//   { "type": "child", "name": "dns",        "node-type": "path" },
//   { "type": "child", "name": "route",      "node-type": "path" },
//   ...
// ]

Getting Syntax Help

// Get description for /ip/address/add → address argument
const syntax = await fetch(`${base}/console/inspect`, {
  method: "POST",
  headers: { ...authHeaders, "Content-Type": "application/json" },
  body: JSON.stringify({
    request: "syntax",
    path: "ip,address,add,address",   // comma-separated path
  }),
}).then(r => r.json());

// Response:
// [{ "type": "syntax", "text": "IP address" }]

Path Format

The path field uses comma-separated segments (not slashes):

  • Root: "" (empty string)
  • /ip: "ip"
  • /ip/address: "ip,address"
  • /ip/address/add: "ip,address,add"
  • /ip/address/add → address arg: "ip,address,add,address"

When using the JavaScript Array.toString() method, this comma-separated format is produced naturally from an array: ["ip", "address", "add"].toString()"ip,address,add".

Tree Traversal Pattern

To walk the entire tree recursively:

async function walkTree(path = [], tree = {}) {
  const children = await fetchInspect("child", path.toString());

  for (const child of children) {
    if (child.type !== "child") continue;

    const childPath = [...path, child.name];
    tree[child.name] = { _type: child["node-type"] };

    // For args, fetch the syntax description — but NOT inside dangerous subtrees
    if (child["node-type"] === "arg") {
      if (DANGEROUS_PATHS.some(p => childPath.includes(p))) continue;

      const syntax = await fetchInspect("syntax", childPath.toString());
      if (syntax.length === 1 && syntax[0].text.length > 0) {
        tree[child.name].desc = syntax[0].text;
      }
    }

    // Recurse into this child (child enumeration is safe even in dangerous subtrees)
    await walkTree(childPath, tree[child.name]);
  }

  return tree;
}

Dangerous Paths — Must Skip

These path segments crash the RouterOS REST server when their arg nodes are queried for syntax via /console/inspect. Always skip syntax lookups for args inside subtrees containing any of these names:

where, do, else, rule, command, on-error

These are RouterOS scripting constructs. Specifically, `fetchSyntax()` on `arg` node-types within these subtrees terminates the HTTP server process. Enumerating children (child request) is safe even inside these paths — only the syntax/description lookup for arguments crashes.

The conservative approach (used in the example above) skips the entire arg when any ancestor matches a dangerous path. The actual rest2raml.js implementation matches this pattern.

const DANGEROUS_PATHS = ["where", "do", "else", "rule", "command", "on-error"];

CLI Command → REST Verb Mapping

RouterOS CLI commands map to HTTP verbs in the REST API:

CLI CommandHTTP VerbREST URL PatternNotes
get (print)GET/rest/ip/addressReturns array of all entries
get (single)GET/rest/ip/address/*1Single entry by ID
addPUT/rest/ip/addressCreates new entry (not POST!)
setPATCH/rest/ip/address/*1Updates existing entry
removeDELETE/rest/ip/address/*1Deletes entry by ID
printPOST/rest/ip/address/printAction-style (also works as GET)
Other commandsPOST/rest/path/commandAction — reboot, flush, etc.

Key insight: REST PUT = create, PATCH = update. This is the opposite of many REST API conventions where PUT is idempotent update and POST is create.

RAML/OpenAPI Schema Generation

When generating API schemas from the command tree:

1. Walk the tree to collect all paths, commands, and arguments 2. For each cmd node:

  • get → generates both GET /path (list) and GET /path/{id} (single)
  • add → generates PUT /path with arg-based request body
  • set → generates PATCH /path/{id} with arg-based request body
  • remove → generates DELETE /path/{id}
  • Other commands → POST /path/command

3. For each arg under a command, generate request body properties or query parameters 4. The desc field from syntax lookups becomes the description

The .proplist and .query Parameters

All POST-based command endpoints accept two special parameters:

  • .proplist — selects which properties to return (like SQL SELECT)
  • .query — filter expression array (like SQL WHERE)

These are RouterOS REST API conventions, not standard REST patterns.

Output Formats

The inspect tree can be converted to multiple schema formats:

inspect.json (Raw Output)

The raw tree as returned by recursive /console/inspect calls. Each node has:

{
  "address": {
    "_type": "path",
    "add": {
      "_type": "cmd",
      "address": { "_type": "arg", "desc": "IP address" },
      "interface": { "_type": "arg", "desc": "Interface name" }
    },
    "set": { "_type": "cmd", ... },
    "print": { "_type": "cmd", ... }
  }
}

RAML 1.0 (schema.raml)

Converted to RAML 1.0 resource/method notation:

/ip:
  /address:
    get:
      queryParameters: ...
      responses: ...
    put:
      body:
        application/json:
          properties:
            address: { type: any, description: "IP address" }
    /{id}:
      get: ...
      patch: ...
      delete: ...

OpenAPI 3.0 (openapi.json)

Standard OpenAPI 3.0 schema generated from the same inspect tree (7.21.1+).

The inspect.json Data Model

Each version's inspect.json is the canonical source of truth for that RouterOS version's command tree. It captures:

  • Every navigable path in the CLI hierarchy
  • Every executable command at each path level
  • Every argument (parameter) for each command
  • Syntax descriptions for arguments

Tools can parse inspect.json offline without needing a live router — set INSPECTFILE env var and the schema generator will use the cached file instead of querying a router.

Common Patterns for Working with the Tree

Finding Commands at a Path

// Given an inspect.json node for /ip/address
const node = inspectData.ip.address;

// Commands are children with _type === "cmd"
const commands = Object.entries(node)
  .filter(([key, val]) => val._type === "cmd")
  .map(([key]) => key);
// → ["add", "set", "remove", "get", "print", "export", ...]

Finding Arguments for a Command

// Arguments of /ip/address/add
const addCmd = inspectData.ip.address.add;
const args = Object.entries(addCmd)
  .filter(([key, val]) => val._type === "arg")
  .map(([key, val]) => ({ name: key, description: val.desc }));
// → [{name: "address", description: "IP address"}, ...]

Traversing Directories

// Directories and paths (navigable children)
const children = Object.entries(node)
  .filter(([key, val]) => val._type === "dir" || val._type === "path")
  .map(([key]) => key);

Performance Notes

  • Full tree traversal takes many minutes against a live router (thousands of HTTP requests,

each a separate POST to /console/inspect). With KVM acceleration the CHR responds quickly, but the sheer number of sequential requests adds up.

  • Each /console/inspect call is a separate HTTP request — no batch API
  • Use INSPECTFILE for development/testing to avoid repeated live queries
  • The tree is version-specific — different RouterOS versions have different command sets
  • Extra packages (container, iot, zerotier, etc.) add additional command tree branches

Additional Resources

  • For REST API details: see routeros-fundamentals skill → REST API patterns
  • For running a CHR to query: see the routeros-qemu-chr skill
  • For /app YAML format (a feature visible in the tree under 7.22+): see the routeros-app-yaml skill

Related skills

FAQ

How is the /console/inspect path formatted?

The path field uses comma-separated segments, e.g. 'ip,address,add', not slashes.

Which subtrees crash the REST server?

Syntax lookups for arg nodes inside where, do, else, rule, command, and on-error subtrees terminate the HTTP server process.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.