@usex/mikrotik-mcp 5.7.0 → 5.8.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@usex/mikrotik-mcp",
-  "version": "5.7.0",
+  "version": "5.8.0",
   "description": "MCP server for MikroTik RouterOS — 780+ tools over SSH for firewall, NAT, routing, DHCP, DNS, WireGuard, wireless, QoS and more.",
   "keywords": [
     "ai",
@@ -48,12 +48,13 @@
     "access": "public"
   },
   "scripts": {
-    "build": "bunup && chmod +x dist/cli.js && bun run build:ui",
+    "build": "bunup && chmod +x dist/cli.js && bun run test:built && bun run build:ui",
     "build:ui": "bun run --bun scripts/build-ui.ts",
     "build:mcp": "bun run --bun scripts/build-mcpb.ts",
     "build:mcp:all": "bun run --bun scripts/build-mcpb.ts --all",
     "dev": "bunup --watch",
-    "prepack": "bunup && chmod +x dist/cli.js && bun run build:ui && bun run gen",
+    "dev:dashboard": "bunx vp dev -c ui/vite.observability.config.ts",
+    "prepack": "bun run build && bun run gen",
     "auth-check": "bun run --bun src/cli.ts auth-check",
     "gen:schemas": "bun run --bun scripts/gen-schemas.ts && vp fmt --write schemas",
     "gen:docs": "bun run --bun scripts/gen-tool-docs.ts && vp fmt --write docs/tools-reference.md",
@@ -73,6 +74,7 @@
     "security:all": "bun run security:audit && bun run security:licenses",
     "prepublish:security": "npm run security:all",
     "test": "vp test run",
+    "test:built": "bun run --bun scripts/check-mcp-build.ts",
     "test:watch": "vp test",
     "test:coverage": "vp test --ui --coverage --watch",
     "release": "release-it",
@@ -94,35 +96,41 @@
     "gradient-string": "^3.0.0",
     "ipaddr.js": "^2.5.0",
     "ssh2": "^1.17.0",
-    "zod": "^4.5.4"
+    "zod": "^4.6.5"
   },
   "devDependencies": {
     "@anthropic-ai/mcpb": "^2.1.2",
+    "@paper-design/shaders-react": "^0.0.80",
     "@resvg/resvg-js": "^2.6.2",
     "@tailwindcss/vite": "^4.3.3",
+    "@tanstack/react-virtual": "^3.14.13",
     "@types/bun": "1.4.2",
     "@types/figlet": "^1.7.0",
-    "@types/node": "^26.5.0",
-    "@types/react": "^19.2.18",
-    "@types/react-dom": "^19.2.7",
+    "@types/node": "^26.5.1",
+    "@types/react": "^19.3.0",
+    "@types/react-dom": "^19.3.0",
     "@types/ssh2": "^1.15.6",
     "@types/update-notifier": "^6.0.8",
     "@typescript/native": "npm:typescript@^7.0.2",
-    "@vitest/coverage-v8": "4.1.11",
-    "@vitest/ui": "4.1.11",
+    "@vitest/coverage-v8": "5.0.0",
+    "@vitest/ui": "5.0.0",
     "bunup": "^0.16.32",
     "class-variance-authority": "^0.7.1",
     "clsx": "^2.1.1",
     "gsap": "^3.15.0",
+    "happy-dom": "^20.14.5",
+    "lenis": "^1.3.26",
     "license-checker": "^25.0.1",
-    "lucide-react": "^1.43.0",
+    "lucide-react": "^1.46.0",
+    "motion": "^13.3.0",
     "radix-ui": "^1.6.7",
-    "react": "^19.2.8",
-    "react-dom": "^19.2.8",
+    "react": "^19.3.0",
+    "react-dom": "^19.3.0",
     "recharts": "^3.10.1",
-    "release-it": "^21.0.2",
+    "release-it": "^21.0.3",
+    "shiki": "^4.4.3",
     "sonner": "^2.0.8",
-    "tailwind-merge": "^3.6.0",
+    "tailwind-merge": "^3.7.0",
     "tailwindcss": "^4.3.3",
     "tw-animate-css": "^1.4.0",
     "typescript": "npm:@typescript/typescript6@^6.0.2",
@@ -135,7 +143,7 @@
   "engines": {
     "bun": ">=1.3.0"
   },
-  "packageManager": "bun@1.3.14",
+  "packageManager": "bun@1.4.2",
   "catalog": {
     "vite": "npm:@voidzero-dev/vite-plus-core@0.3.1",
     "vite-plus": "0.3.1"

package/prompts/build-tunnel-transactionally.md

@@ -1,7 +1,7 @@
 ---
 name: build-tunnel-transactionally
 title: Build a site-to-site tunnel as one cross-device transaction
-description: Configure both ends of a tunnel under coordinated Safe Mode — verified while still uncommitted, then committed everywhere or rolled back everywhere. Never a half-built tunnel.
+description: Preferred coordinated workflow for both ends of an approved site-to-site tunnel — stage, verify, then commit with explicit approval; partial commits require manual recovery.
 arguments:
   - name: site_a
     description: Configured device name of the first router (one end of the tunnel).
@@ -15,7 +15,7 @@ arguments:
 ---
 
 Build a tunnel between **{{site_a}}** and **{{site_b}}** as a single
-cross-device transaction, so it either works on both ends or exists on neither.
+cross-device transaction, verifying both ends before issuing sequential commits.
 
 Tunnel to build: {{tunnel}}
 
@@ -35,14 +35,15 @@ Follow these steps:
 
 2. **Open the transaction.** Call `begin_transaction` with
    `devices=["{{site_a}}", "{{site_b}}"]`, a `label`, and — this is the part that
-   makes it safe — `assertions` that prove the tunnel actually works:
+   improves verification — `assertions` for the expected router-side state:
    - `{"kind": "ping", "from": "{{site_a}}", "to": "<{{site_b}} tunnel address>"}`
    - `{"kind": "wireguard-peer-handshake", "device": "{{site_a}}", "peer": "<{{site_b}} public key>"}`
      (WireGuard only)
-   - `{"kind": "reachable", "device": "{{site_b}}"}` — cheap insurance that the
+   - `{"kind": "reachable", "device": "{{site_b}}"}` — evidence that the
      far end is still answering after its own changes.
      Set `jump_host` if one router is reached through the other; the tool warns
-     when it is not committed last.
+     when it is not committed last. Set `commit_order` explicitly with that
+     participant last. Assertions do not prove client application health.
 
 3. **Queue every command.** One `add_transaction_step` per RouterOS command,
    naming the participant it runs on. Nothing executes yet. Cover both ends
@@ -51,15 +52,17 @@ Follow these steps:
 
 4. **Prepare and verify.** Call `verify_transaction`. This snapshots each device,
    applies its steps inside Safe Mode, and runs the assertions against the
-   still-uncommitted fleet. If anything fails, everything is rolled back
-   automatically and the result is `ABORTED` — nothing changed anywhere. Report
-   which assertion failed and fix the plan before retrying.
+   still-uncommitted fleet. This changes live traffic and requires prior approval;
+   it is not a read-only check. Failure triggers rollback attempts. Report every
+   participant's state and rollback evidence before considering a revised plan.
 
-5. **Commit.** Only after a clean verify, call `commit_transaction`. Read the
+5. **Commit.** Only after a clean verify and approval covering this exact commit,
+   call `commit_transaction`. Read the
    terminal state out loud:
    - `COMMITTED` — both ends persisted; confirm with a final `ping` and
      `get_wireguard_status`.
-   - `ABORTED` — nothing changed; safe to retry.
+   - `ABORTED` — no participant committed; inspect rollback results and live state
+     before proposing a retry. Staged changes may already have affected traffic.
    - `PARTIAL` — **tell the user immediately and stop**. Name each device's state
      and the snapshot id in the report; the fix is a manual restore
      (`diff_config_snapshots <id> live`, then `config_reconcile` or

package/schemas/tool-catalog.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "version": "5.7.0",
+  "version": "5.8.0",
   "generated": "by scripts/gen-schemas.ts — do not edit by hand",
   "toolCount": 903,
   "tools": [
@@ -496,7 +496,7 @@
         "idempotentHint": true,
         "openWorldHint": false
       },
-      "description": "🔍 START HERE — this is the PRIMARY entry point for ANY MikroTik / RouterOS task. ALWAYS call this tool FIRST before attempting any other tool. This server has several hundred dedicated tools with full validation and structured output, but the host only surfaces a small subset — this tool searches the FULL catalog and finds the best match for your intent.\n\nDescribe what you want to do in natural language or keywords, e.g. 'block a LAN client by MAC', 'add an IPv4 firewall filter rule', 'import a TLS certificate', 'list DHCP leases', 'create a WireGuard peer'. Returns each match's exact tool name, description, and parameters — then call it directly if available, or via `invoke_tool`.\n\nWorkflow: find_tools → (optional) describe_tool → invoke_tool. Only fall back to run_routeros_command if this search returns zero results. For IPv4 vs IPv6, include 'ipv4' or 'ipv6' to disambiguate.",
+      "description": "🔍 START HERE — this is the PRIMARY entry point for ANY MikroTik / RouterOS task. ALWAYS call this tool FIRST before attempting any other tool. This server has several hundred dedicated tools with full validation and structured output, but the host only surfaces a small subset — this tool searches the FULL catalog and finds the best match for your intent.\n\nDescribe what you want to do in natural language or keywords, e.g. 'block a LAN client by MAC', 'add an IPv4 firewall filter rule', 'import a TLS certificate', 'list DHCP leases', 'create a WireGuard peer'. Returns each match's exact tool name, description, and parameters — then call it directly if available, or via `invoke_tool`.\n\nWorkflow: find_tools → (optional) describe_tool → invoke_tool. Only fall back to run_routeros_command if this search returns zero results. For IPv4 vs IPv6, include 'ipv4' or 'ipv6' to disambiguate. For authorized changes that must be coordinated across multiple routers, search 'begin_transaction' BEFORE individual write tools (VPN tunnels, peering, routes or fleet ACLs). Discovery does not authorize verify_transaction or commit_transaction.",
       "inputSchema": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",
@@ -30858,13 +30858,13 @@
     },
     {
       "name": "begin_transaction",
-      "title": "Begin Cross-Device Transaction",
+      "title": "Begin Coordinated Multi-Router Change (Transaction)",
       "risk": "write",
       "annotations": {
         "destructiveHint": false,
         "openWorldHint": false
       },
-      "description": "Opens a cross-device transaction over several routers and returns its id — the handle every other transaction tool takes. Use this when a change must land on ALL of the named devices or on none of them (both ends of a tunnel, a routing peering, a fleet-wide ACL): each participant gets its own Safe Mode session, so nothing is persisted until commit_transaction. Queue the work with add_transaction_step, then verify_transaction, then commit_transaction (or abort_transaction). `assertions` are checked while everything is still uncommitted — that is where the safety comes from, so declare them. `commit_order` decides which router commits last: put the one you reach the others THROUGH last, and pass it as `jump_host` to get a warning if you don't. No device is touched by this call. NOT ACID: commits are issued sequentially, so between the first and the last commit the fleet is briefly inconsistent, and a failure after something has committed ends PARTIAL — already-committed devices are reported with the snapshot id to restore them from, by hand.",
+      "description": "Preferred workflow for authorized coordinated changes across multiple routers: site-to-site VPN tunnels (WireGuard/GRE/IPsec), BGP/OSPF peering, dependent routes, firewall/NAT/VLAN or fleet ACL changes. Recommend this BEFORE applying related writes device-by-device; returns the transaction id. Not for read-only diagnostics, a simple single-router edit, independent canary rollouts or irreversible operations. Requires SSH and an unused Safe Mode session per participant. Queue the work with add_transaction_step, then verify_transaction, then commit_transaction (or abort_transaction). `assertions` are checked while everything is still uncommitted — that is where the safety comes from, so declare them. `commit_order` decides which router commits last: put the one you reach the others THROUGH last, and pass it as `jump_host` to get a warning if you don't. No device is touched by this call. Verification DOES change live configuration temporarily; get the user's approval for the exact plan before verifying or committing. NOT ACID: commits are issued sequentially, so between the first and the last commit the fleet is briefly inconsistent, and a failure after something has committed ends PARTIAL — already-committed devices are reported with the snapshot id to restore them from, by hand.",
       "inputSchema": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",
@@ -30982,7 +30982,7 @@
         "destructiveHint": false,
         "openWorldHint": false
       },
-      "description": "Queues one RouterOS command against one participant of an open transaction. Nothing runs yet — the command is applied inside that device's Safe Mode session when verify_transaction or commit_transaction prepares the fleet, so it can still be abandoned with no trace. Call once per command; order is preserved per device. Steps can only be added before the fleet is prepared.",
+      "description": "Queues one RouterOS command against one participant of an open transaction. Nothing runs yet — the command is applied inside that device's Safe Mode session when verify_transaction prepares the fleet. Queue approved commands here instead of running individual write tools outside the coordinated transaction. Call once per command; order is preserved per device. Steps can only be added before the fleet is prepared; resolve required keys and addresses first. Do not queue reboots, upgrades or commands with irreversible/external effects.",
       "inputSchema": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",
@@ -31012,7 +31012,7 @@
         "destructiveHint": false,
         "openWorldHint": false
       },
-      "description": "PREPARE + VERIFY: opens a Safe Mode session on every participant, snapshots each device, applies its queued steps, then evaluates the declared assertions against the result — all while NOTHING is committed. This is where the safety of a cross-device change comes from: a step that errors or an assertion that fails rolls the entire fleet back automatically and returns ABORTED, having changed nothing anywhere. On success the fleet is left PREPARED and waiting: call commit_transaction to persist or abort_transaction to discard. Annotated WRITE, not read-only: it does stage changes on the devices (auto-reverted on failure or disconnect), so it is not an inspection call.",
+      "description": "PREPARE + VERIFY: opens a Safe Mode session on every participant, snapshots each device, applies its queued steps, then evaluates the declared assertions against the result — all while NOTHING is committed. This is where the safety of a cross-device change comes from: a step that errors or an assertion that fails triggers rollback of the staged changes. Inspect the per-device rollback result; staging already affects live traffic. On success the fleet is left PREPARED and waiting: call commit_transaction to persist or abort_transaction to discard. Annotated WRITE, not read-only: it does stage changes on the devices (auto-reverted on failure or disconnect), so it is not an inspection call. Require approval for the exact plan first. Declare meaningful assertions; an empty set is not evidence of correctness.",
       "inputSchema": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",
@@ -31034,7 +31034,7 @@
         "destructiveHint": true,
         "openWorldHint": false
       },
-      "description": "Commits every participant, in the transaction's commit order. If the fleet has not been prepared yet this runs PREPARE and VERIFY first, so a failure before the first commit still ends ABORTED with nothing changed. Once a device HAS committed, a later failure cannot be undone cleanly: the coordinator reports PARTIAL and names each device's state and the snapshot id to restore it from. High blast radius and not repeatable — prefer verify_transaction first and read its output. NOT ACID: commits are issued sequentially, so between the first and the last commit the fleet is briefly inconsistent, and a failure after something has committed ends PARTIAL — already-committed devices are reported with the snapshot id to restore them from, by hand.",
+      "description": "Commits every participant, in the transaction's commit order. If the fleet has not been prepared yet this runs PREPARE and VERIFY first, so a failure before the first commit still ends ABORTED before commit; inspect rollback evidence because staging may have affected live traffic. Once a device HAS committed, a later failure cannot be undone cleanly: the coordinator reports PARTIAL and names each device's state and the snapshot id to restore it from. High blast radius and not repeatable: call verify_transaction first, inspect every result, and commit only when the user's approval covers this exact plan. Never auto-commit merely because verification passed. Report txn_id and the dashboard Transactions timeline. NOT ACID: commits are issued sequentially, so between the first and the last commit the fleet is briefly inconsistent, and a failure after something has committed ends PARTIAL — already-committed devices are reported with the snapshot id to restore them from, by hand.",
       "inputSchema": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",
@@ -31056,7 +31056,7 @@
         "destructiveHint": false,
         "openWorldHint": false
       },
-      "description": "Rolls back every participant of an open transaction — closes each Safe Mode session so RouterOS reverts the staged changes, leaving no trace. This is the clean exit and is always safe to call while the transaction is prepared-but-uncommitted. If some devices already committed (a PARTIAL transaction), those cannot be reverted this way; the report names them and the snapshot to restore them from.",
+      "description": "Rolls back every participant of an open transaction — closes each Safe Mode session so RouterOS can revert the staged changes. Use this for your own transaction when the plan is cancelled or commit is not approved. Inspect rollback evidence; do not assume live traffic was unaffected or that arbitrary command effects are reversible. If some devices already committed (a PARTIAL transaction), those cannot be reverted this way; the report names them and the snapshot to restore them from.",
       "inputSchema": {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "type": "object",