@usex/mikrotik-mcp 3.51.1 → 3.52.0

package/prompts/troubleshoot-network.md

@@ -0,0 +1,45 @@
+---
+name: troubleshoot-network
+title: Intelligent root-cause diagnosis
+description: Autonomously investigate a network problem across connectivity, routing, firewall, NAT, DHCP, DNS, and system resources — ranked hypotheses with fix commands.
+arguments:
+  - name: symptom
+    description: Describe the problem in plain language (e.g. "users on VLAN 20 can't reach the internet", "BGP session to 10.0.0.1 keeps dropping").
+    required: true
+  - name: scope
+    description: Limit investigation to specific dimensions (comma-separated). Options — connectivity, interfaces, routing, firewall, nat, dhcp, dns, resources, logs, vpn. Omit for full investigation.
+    required: false
+---
+
+Investigate a network problem on this MikroTik device using the intelligent
+root-cause analyzer. It autonomously probes across up to 10 dimensions and
+correlates evidence into ranked hypotheses.
+
+Symptom: {{symptom}}
+Investigation scope: {{scope}}
+
+Follow this workflow:
+
+1. **Automated diagnosis.** Call `diagnose` with the symptom description (and
+   optional scope). It will autonomously investigate connectivity, interfaces,
+   routing (BGP/OSPF), firewall, NAT, ARP/DHCP, DNS, CPU/memory, logs, and VPN —
+   then return ranked root-cause hypotheses with confidence levels.
+
+2. **Review hypotheses.** Present each hypothesis with:
+   - Confidence level (high/medium/low).
+   - The evidence that supports it.
+   - The specific fix command(s) provided.
+
+3. **Deep-dive if needed.** For the top hypothesis:
+   - If routing is involved, call `trace_path` for hop-by-hop path analysis.
+   - If logs suggest cascading failures, call `correlate_events` to surface the
+     chain (e.g. interface down → OSPF neighbor lost → route withdrawn).
+
+4. **Quick fix option.** Call `suggest_fix` for a condensed list of actionable
+   commands with one-line explanations — useful when you just need the fix
+   without the full diagnostic report.
+
+5. **Apply fix (with approval).** Present the recommended fix commands and apply
+   only after the user approves. Use Safe Mode for firewall changes.
+
+Do not apply any changes without user approval.

package/prompts/upgrade-firmware.md

@@ -0,0 +1,48 @@
+---
+name: upgrade-firmware
+title: Upgrade RouterOS firmware safely
+description: Check for updates, capture a health baseline, stage packages, and apply the upgrade with automatic rollback on failure.
+arguments:
+  - name: channel
+    description: Update channel — "stable", "long-term", or "testing". Default is the device's current channel.
+    required: false
+---
+
+Upgrade this MikroTik device's RouterOS firmware safely. The upgrade pipeline
+captures a health baseline before upgrading so you can verify the device is
+healthy afterwards — and RouterOS will automatically fall back to the previous
+version if the upgrade fails.
+
+Update channel: {{channel}}
+
+Follow these steps in order:
+
+1. **Check for updates.** Call `firmware_check` to discover available versions,
+   compare against the current version, and assess upgrade readiness (CPU load,
+   free memory, version jump size). If no update is available, report that and
+   stop.
+
+2. **Capture a restore point.** Call `capture_config_snapshot` with
+   `label=pre-upgrade` to store the current `/export` locally. This is your
+   rollback reference — zero footprint on the device's flash.
+
+3. **Review the upgrade plan.** Present: current version → target version, the
+   version jump (major/minor/patch), and any readiness warnings from step 1.
+   Confirm with the user before proceeding.
+
+4. **Stage the packages.** Call `firmware_stage` to pre-download the update
+   packages without rebooting. This lets you verify the download succeeds before
+   committing to the reboot.
+
+5. **Apply the upgrade.** Call `firmware_upgrade` to install and reboot. The
+   device will come back on the new version. If it fails to boot, RouterOS
+   automatically falls back to the previous version.
+
+6. **Verify post-upgrade health.** Call `firmware_status` — it compares the
+   current system health against the pre-upgrade baseline and reports any
+   regressions (CPU, memory, package changes, RouterBOARD firmware status).
+
+7. **Confirm.** Report the old version, new version, health comparison, and
+   whether the RouterBOARD firmware also needs upgrading (if applicable).
+
+Do not proceed past step 3 without user approval.