@usex/mikrotik-mcp 3.51.0 → 3.52.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@usex/mikrotik-mcp",
-  "version": "3.51.0",
+  "version": "3.52.0",
   "description": "MCP server for MikroTik RouterOS — 660+ tools over SSH for firewall, NAT, routing, DHCP, DNS, WireGuard, wireless, QoS and more.",
   "keywords": [
     "ai",

package/prompts/audit-security-posture.md

@@ -0,0 +1,41 @@
+---
+name: audit-security-posture
+title: Run a compliance security audit
+description: Comprehensive security audit across SSH, services, firewall, users, DNS, certificates, SNMP, hardening, and VPN — scored A+ through F with actionable fix commands.
+arguments:
+  - name: categories
+    description: Comma-separated categories to audit (e.g. "ssh,firewall,users"). Omit for a full audit across all 9 categories.
+    required: false
+---
+
+Run a comprehensive security compliance audit on this MikroTik device. The audit
+covers 36 checks across 9 categories — SSH, management services, firewall, user
+accounts, DNS, certificates, SNMP, system hardening, and VPN — and scores the
+device from A+ (excellent) down to F (critical).
+
+Categories to audit: {{categories}}
+
+Follow this workflow:
+
+1. **Run the audit.** Call `run_compliance_audit` (optionally filtered to
+   `{{categories}}`). Review the per-check results: each check reports pass, fail,
+   or warn with a severity level and a specific fix command.
+
+2. **Present the results.** Organize findings by severity (critical → low):
+   - The overall grade (A+ through F) and numeric score.
+   - A summary table of failed and warning checks.
+   - For each failing check: what it found, why it matters, and the exact fix
+     command provided by the audit engine.
+
+3. **Remediate (with user approval).** If the user wants to fix failing checks,
+   call `audit_remediate` with `dry_run=true` first to preview what commands would
+   run. Then, with approval, call `audit_remediate` with `dry_run=false` to apply.
+
+4. **Re-audit.** After remediation, run `run_compliance_audit` again to confirm
+   the score improved and no new issues were introduced.
+
+5. **Fleet-wide (optional).** If multiple devices are configured, offer to run
+   `audit_fleet` for a consolidated report with aggregate scores and the most
+   common failures across the fleet.
+
+Do not apply any fixes without user approval. Present the audit report first.

package/prompts/backup-and-document.md

@@ -9,9 +9,12 @@ Create a restore point for this MikroTik device and then write up a clear,
 human-readable summary of how it's configured. This is read-mostly: the only
 change is creating a backup/export.
 
-1. **Restore point** — `create_backup` (binary, for full restore) and
+1. **Local snapshot (zero device footprint)** — `capture_config_snapshot` first.
+   This stores a text `/export` in the MCP host's local database — no file is
+   written on the router's flash. Give it a descriptive `label` (e.g. `pre-audit`).
+2. **Device restore point** — `create_backup` (binary, for full restore) and
    `create_export` (text `.rsc`, for review/diff). List them with `list_backups`.
-2. **Inventory** — gather the configuration with read tools and organize it:
+3. **Inventory** — gather the configuration with read tools and organize it:
    - System: `get_system_identity`, `get_system_resources`, `get_routerboard`,
      `get_installed_packages`.
    - L2/L3: `list_interfaces`, `list_vlan_interfaces`, `list_bridges`,
@@ -23,10 +26,12 @@ change is creating a backup/export.
      `list_users`, `list_certificates`.
    - VPN/QoS: `list_wireguard_interfaces` + `list_wireguard_peers`,
      `list_simple_queues`, `list_queue_trees`.
+   - Containers: `list_containers` (if the container feature is enabled).
    - Automation: `list_schedulers`, `list_scripts`.
 
 Produce a structured Markdown report: a one-paragraph overview, a table of
 interfaces and addressing, the firewall posture, and a "things worth reviewing"
-section (defaults left in place, disabled-but-present rules, expiring certs).
-Reference the backup/export filenames you created so the user knows their restore
-point.
+section (defaults left in place, disabled-but-present rules, expiring certs —
+check `list_certificates` for any expiring within 30 days).
+Reference the snapshot id and backup/export filenames you created so the user
+knows their restore points.

package/prompts/choose-vpn-solution.md

@@ -23,6 +23,9 @@ Decision guidance — weigh these MikroTik options:
 - **WireGuard** — fastest, simplest, modern. Best for MikroTik↔MikroTik and
   laptops/phones with the WireGuard app. No built-in OS client on older systems.
   Tools: `create_wireguard_interface`, `add_wireguard_peer`, `generate_wireguard_client_config`.
+  For **3+ sites** (full-mesh or hub-spoke): `build_wireguard_mesh`.
+  For **user onboarding** (generate config, add peer, revoke later):
+  `onboard_wireguard_user`, `revoke_wireguard_user`.
 - **IPsec (IKEv2)** — the interoperability choice for site-to-site with
   _other vendors_ (Cisco/Fortinet/pfSense) and for native iOS/Windows IKEv2
   road-warrior. Most config surface. Tools: `create_ipsec_*` (profile/peer/

package/prompts/design-qos-policy.md

@@ -0,0 +1,49 @@
+---
+name: design-qos-policy
+title: Design a traffic shaping policy
+description: Build a QoS queue hierarchy from business requirements — define traffic classes, priorities, and bandwidth guarantees with preview before apply.
+arguments:
+  - name: wan_bandwidth
+    description: WAN bandwidth in download/upload format (e.g. "100M/50M", "1G/1G").
+    required: true
+  - name: classes
+    description: Describe traffic classes and priorities (e.g. "VoIP=highest, video conferencing=high, web=normal, bulk downloads=low"). If omitted, a sensible default is used.
+    required: false
+---
+
+Design and deploy a traffic shaping (QoS) policy on this MikroTik device that
+prioritizes important traffic and prevents bulk downloads from saturating the
+link. All changes are previewed before applying.
+
+WAN bandwidth: {{wan_bandwidth}}
+Traffic classes: {{classes}}
+
+Steps:
+
+1. **Understand the network.** Call `list_interfaces` and `list_ip_addresses` to
+   identify the WAN interface. Call `list_queue_trees` and `list_simple_queues`
+   to check if any QoS is already in place.
+
+2. **Design the policy.** Translate {{classes}} into a queue hierarchy:
+   - A parent queue on the WAN interface capped at {{wan_bandwidth}}.
+   - Child queues for each traffic class with appropriate priorities,
+     guaranteed minimum bandwidth, and burst settings.
+     Call `apply_traffic_shaping` in **preview mode** to see the queue tree
+     structure before applying.
+
+3. **Review the queue tree.** Present a table showing:
+   - Each traffic class, its priority level, guaranteed bandwidth, max bandwidth.
+   - Packet marks or connection marks used to classify traffic.
+   - Mangle rules that mark traffic into classes.
+
+4. **Apply.** With user approval, deploy the QoS policy.
+
+5. **Verify.** Call `list_queue_trees` to confirm the hierarchy is in place.
+   Monitor briefly to see traffic flowing through the queues.
+
+6. **Capacity planning (optional).** Call `forecast_link_saturation` on the WAN
+   interface to project when the current link will reach capacity at the observed
+   growth rate — useful for planning upgrades.
+
+Report the complete QoS policy: queue hierarchy, classification rules, and
+bandwidth allocations per class.

package/prompts/detect-config-drift.md

@@ -0,0 +1,51 @@
+---
+name: detect-config-drift
+title: Detect and resolve config drift
+description: Compare live router config against a golden baseline, identify who changed what and when, then roll back or accept the drift.
+arguments:
+  - name: action
+    description: What to do — "check" (detect drift), "reconcile" (roll back to baseline), or "promote" (accept drift as new baseline). Default is "check".
+    required: false
+---
+
+Work with the Config Drift Guardian on this MikroTik device. The drift system
+compares the live `/export` against a stored golden baseline and reports exactly
+what changed, who changed it (from system logs), and scores the severity 0–100.
+
+Requested action: {{action}}
+
+Follow the workflow for the requested action:
+
+**If checking (or no action specified):**
+
+1. **Verify baseline exists.** Call `config_check_drift`. If it reports "no
+   baseline set", guide the user to set one first with `config_set_baseline`
+   (captures the current config as the known-good reference).
+
+2. **Review the drift report.** Present:
+   - Drift score (0–100) and overall status (in-sync or drifted).
+   - Per-section breakdown: which RouterOS sections changed and by how much.
+   - Change attribution: who made each change and when (from system logs).
+   - The unified diff showing exact added/removed lines.
+
+3. **Recommend next steps.** Based on the drift:
+   - If changes are intentional → suggest `config_promote_drift` to accept.
+   - If changes are unwanted → suggest `config_reconcile` to roll back.
+
+**If reconciling:**
+
+1. Call `config_reconcile` with `confirm=false` first (dry-run). This replays the
+   baseline commands in Safe Mode and then rolls back, showing what would change.
+2. Review the dry-run output with the user.
+3. With approval, call `config_reconcile` with `confirm=true` to commit. Safe Mode
+   ensures automatic rollback if the device becomes unreachable.
+
+**If promoting:**
+
+1. Call `config_promote_drift` to accept the current live config as the new golden
+   baseline. Optionally provide a `label` and `notes` explaining why the drift is
+   being accepted.
+2. Confirm the new baseline ID and that the old baseline is preserved in snapshot
+   history.
+
+Always explain the consequences before taking action.

package/prompts/diagnose-connectivity.md

@@ -15,6 +15,11 @@ Troubleshoot a connectivity issue on a MikroTik RouterOS device, reasoning from
 the bottom of the stack up. Use read-only tools only — do not change config until
 you've localized the fault and the user approves a fix.
 
+**Quick alternative:** for a fully automated diagnosis, call `diagnose` with the
+symptom description — it autonomously investigates across 10 dimensions and
+returns ranked root-cause hypotheses with fix commands. Use the manual steps below
+when you need more control or the automated diagnosis needs a deeper look.
+
 Target that is unreachable: {{target}}
 Affected segment/interface: {{source_interface}}
 
@@ -24,16 +29,21 @@ Diagnose in layers, stating what each step rules in or out:
    PoE/SFP links check status. `get_interface` for details.
 2. **Addressing** — `list_ip_addresses`; confirm the segment has a valid gateway
    IP and the WAN has an address (DHCP/PPPoE/static).
-3. **Routing** — `get_routing_table`, then `check_route_path` toward {{target}} to
+3. **ARP & DHCP** — `list_dhcp_servers` and `list_dhcp_leases` on the affected
+   segment; confirm clients are getting leases and ARP is resolving.
+4. **Routing** — `get_routing_table`, then `check_route_path` toward {{target}} to
    see which route/gateway would be used and whether it's active.
-4. **Name resolution** — if {{target}} is a hostname, `resolve_dns` and
+5. **Name resolution** — if {{target}} is a hostname, `resolve_dns` and
    `get_dns_settings`.
-5. **Reachability** — `ping` {{target}} from the router (and with `src_address`
+6. **Reachability** — `ping` {{target}} from the router (and with `src_address`
    set to the segment's gateway if relevant); `traceroute` to find where it stops.
-6. **Firewall / NAT** — `list_filter_rules` and `list_nat_rules`; look for a drop
+7. **Firewall / NAT** — `list_filter_rules` and `list_nat_rules`; look for a drop
    in `forward` or a missing `srcnat`/masquerade for the segment. Check
    `list_address_lists` if rules reference one.
-7. **Logs** — `search_logs` for the interface/subnet and `get_system_events`.
+8. **Logs & event correlation** — `search_logs` for the interface/subnet and
+   `get_system_events`. If multiple log entries suggest cascading failures (e.g.
+   interface down → OSPF neighbor lost → route withdrawn), use `correlate_events`
+   to surface the chain.
 
 Conclude with the single most likely root cause, the evidence for it, and the
 specific tool call(s) that would fix it (for the user to approve).

package/prompts/disaster-recovery-drill.md

@@ -0,0 +1,43 @@
+---
+name: disaster-recovery-drill
+title: Rehearse a disaster recovery scenario
+description: Simulate a failure in Safe Mode, verify the backup/restore path works, then auto-revert — proving your DR plan without risk.
+arguments:
+  - name: scenario
+    description: What failure to simulate (e.g. "lose WAN interface", "delete all firewall rules", "disable OSPF", "remove default route"). If omitted, a sensible scenario will be chosen.
+    required: false
+---
+
+Rehearse a disaster recovery scenario on this MikroTik device **without any
+lasting impact**. The drill uses RouterOS Safe Mode to simulate a failure, verify
+the backup and restore path works, then auto-revert everything. This proves your
+DR plan actually works — safely.
+
+Scenario to simulate: {{scenario}}
+
+Follow these steps:
+
+1. **Take a restore point.** Call `capture_config_snapshot` with
+   `label=pre-dr-drill` so you have a reference even outside Safe Mode.
+
+2. **Run the drill.** Call `run_failover_drill` with the scenario description.
+   The drill will:
+   - Enter Safe Mode (all changes auto-revert if something goes wrong).
+   - Apply the simulated failure (e.g. disable the WAN interface).
+   - Assess the impact: what broke, what services are affected.
+   - Verify the recovery path: can the backup restore the state?
+   - Auto-revert all changes — the device returns to its pre-drill state.
+
+3. **Review the drill report.** Present:
+   - What was simulated and what broke as a result.
+   - Whether the backup/restore path would have recovered the device.
+   - Time to recovery (how long the revert took).
+   - Any gaps in the DR plan (e.g. no backup exists, restore would miss X).
+
+4. **Recommendations.** Based on the drill results, suggest improvements:
+   - Missing backups or snapshots to create.
+   - Configuration changes that would improve resilience.
+   - Monitoring or alerting to add (e.g. netwatch for the WAN link).
+
+The drill is **non-destructive** — Safe Mode ensures everything reverts. Report
+the full drill outcome and recommendations.

package/prompts/fleet-health-check.md

@@ -0,0 +1,41 @@
+---
+name: fleet-health-check
+title: Fleet-wide health and compliance sweep
+description: Check reachability, resource usage, firmware currency, security posture, and config drift across all configured devices.
+arguments: []
+---
+
+Run a comprehensive health and compliance sweep across **all configured MikroTik
+devices** accessible through this server. This is a read-only operation — no
+changes are made.
+
+Steps:
+
+1. **List all devices.** Call `list_devices` to get every configured device and
+   its connection status.
+
+2. **Per-device health check.** For each reachable device (pass `device=<name>`
+   on each tool call):
+   - **System resources:** `get_system_resources` — CPU load, memory usage, disk
+     usage, uptime. Flag any device above 80% CPU or memory.
+   - **Firmware currency:** `firmware_check` — is an update available? How far
+     behind is the installed version?
+   - **Security posture:** `run_compliance_audit` — get the A+ through F grade
+     and count of critical/warning findings.
+   - **Config drift:** `config_check_drift` — if a golden baseline is set, report
+     whether the device has drifted and the severity score. Skip if no baseline.
+
+3. **Fleet summary.** Present a consolidated report:
+   - A table with one row per device: name, status, CPU%, memory%, firmware
+     version, update available, compliance grade, drift status.
+   - **Alerts:** devices with critical resource usage, outdated firmware, poor
+     compliance scores, or unresolved drift.
+   - **Prioritized actions:** what to address first (e.g. "device-X has an F
+     security grade — run the hardening prompt", "device-Y is 3 versions behind —
+     run the firmware upgrade prompt").
+
+4. **Unreachable devices.** List any devices that couldn't be reached and suggest
+   troubleshooting steps (check SSH connectivity, credentials, network path).
+
+This is a reporting-only sweep. Recommend specific prompts or tools for each
+finding but do not make changes.

package/prompts/harden-router.md

@@ -33,6 +33,16 @@ Carry out a hardening pass in this order, explaining each finding:
    bandwidth-test left open on the WAN.
 6. **DNS** — `get_dns_settings`; if `allow-remote-requests` is yes, ensure UDP/TCP
    53 from WAN is dropped.
+7. **SSH hardening** — `get_ssh_server_settings`; recommend strong-crypto only,
+   disable password auth if SSH keys are already deployed for admin users, and
+   consider changing the default port.
+8. **Automated DDoS / brute-force protection** — consider `harden_firewall` (the
+   Security Shield) to deploy rate-limiting rules for SSH/Winbox brute-force,
+   SYN floods, port scans, and IP spoofing in one step.
+9. **Full compliance audit** — for a comprehensive automated check across all 36
+   security dimensions, run `run_compliance_audit`. It scores the device A+
+   through F and provides per-check fix commands. Use this to catch anything the
+   manual steps above may have missed.
 
 Finish with a short prioritized checklist (Critical / Recommended / Optional) and
 the exact tool calls you would run for each. Do not make changes the user hasn't

package/prompts/manage-certificates.md

@@ -0,0 +1,51 @@
+---
+name: manage-certificates
+title: Manage TLS certificates and Let's Encrypt
+description: Audit certificate expiry, issue or renew Let's Encrypt certificates via ACME, and deploy them to services.
+arguments:
+  - name: domain
+    description: Domain name for Let's Encrypt issuance (e.g. "router.example.com"). Required for issuing new certificates.
+    required: false
+  - name: action
+    description: What to do — "audit" (check expiry), "issue" (new Let's Encrypt cert), or "renew" (renew expiring certs). Default is "audit".
+    required: false
+---
+
+Manage TLS certificates on this MikroTik device — audit expiry dates, issue new
+certificates via Let's Encrypt (ACME), and deploy them to services.
+
+Domain: {{domain}}
+Action: {{action}}
+
+Follow the workflow for the requested action:
+
+**If auditing (or no action specified):**
+
+1. Call `audit_certificate_expiry` to scan all installed certificates. It reports
+   each certificate's subject, issuer, expiry date, and days remaining.
+2. Flag any certificates expiring within 30 days as **urgent**, within 90 days as
+   **warning**.
+3. For expiring certificates, recommend renewal — either via ACME for Let's
+   Encrypt certs, or manual replacement for CA-signed certs.
+4. Call `list_certificates` for a full inventory including self-signed and CA certs.
+
+**If issuing a new certificate:**
+
+1. Confirm {{domain}} resolves to this router's public IP (for HTTP-01 challenge).
+2. Ensure port 80 is accessible from the internet (check `list_nat_rules` and
+   `list_filter_rules` for port 80).
+3. Call `request_letsencrypt_certificate` with the domain name.
+4. Verify issuance with `list_certificates` — the new cert should appear with
+   the Let's Encrypt issuer.
+5. Deploy the cert to the relevant service (e.g. `set_ip_service` for www-ssl,
+   or configure it for SSTP/OpenVPN).
+
+**If renewing:**
+
+1. Call `audit_certificate_expiry` to identify which certs need renewal.
+2. For each expiring Let's Encrypt cert, call `request_letsencrypt_certificate`
+   with the same domain to renew.
+3. Verify renewal with `list_certificates`.
+4. Recommend setting up a scheduler script for automatic renewal (e.g. monthly).
+
+Report all certificate changes and service assignments.

package/prompts/safe-change-workflow.md

@@ -43,5 +43,11 @@ Follow these steps in order — never skip the snapshot.
    `get_config_snapshot` (it returns the full `/export` `.rsc` text) and use it to
    reverse the change.
 
+6. **Set a golden baseline (optional).** If the change is intentional and
+   permanent, call `config_set_baseline` to designate the new state as the
+   golden-config baseline. Future drift can then be detected automatically with
+   `config_check_drift` — it reports exactly what changed, who changed it (from
+   system logs), and scores the severity.
+
 Report: the snapshot id you captured, the plan summary, the committed diff, and
 the post-change verification result.

package/prompts/setup-bgp-peering.md

@@ -0,0 +1,57 @@
+---
+name: setup-bgp-peering
+title: Set up BGP peering
+description: Configure a BGP connection to a peer — upstream provider, IX, or another router — with templates, filters, and session verification.
+arguments:
+  - name: peer_address
+    description: Neighbor IP address (e.g. "198.51.100.1").
+    required: true
+  - name: remote_as
+    description: Peer AS number (e.g. "65000").
+    required: true
+  - name: local_as
+    description: Local AS number. If omitted, defaults to the existing BGP AS or the router-id-based AS.
+    required: false
+---
+
+Configure a BGP peering session on this MikroTik device. This sets up the BGP
+template, connection, and verification. Confirm the plan before applying.
+
+Peer address: {{peer_address}}
+Remote AS: {{remote_as}}
+Local AS: {{local_as}}
+
+Steps:
+
+1. **Check existing BGP config.** Call `list_bgp_templates` and
+   `list_bgp_connections` to see if BGP is already configured. Call
+   `list_ip_addresses` to confirm we have a local IP in the same subnet as the
+   peer (or a route to reach it).
+
+2. **Create a BGP template.** Call `add_bgp_template` with:
+   - `as={{local_as}}` (or the existing AS).
+   - Address families (typically `ip` for IPv4 unicast; add `ipv6` if needed).
+   - Hold time, keepalive, and other timers as appropriate.
+
+3. **Create the BGP connection.** Call `add_bgp_connection` with:
+   - `remote.address={{peer_address}}`
+   - `remote.as={{remote_as}}`
+   - `local.role` — set to `ebgp` for external peers, `ibgp` for internal.
+   - Link to the template created in step 2.
+
+4. **Firewall.** Ensure TCP port 179 (BGP) is allowed from {{peer_address}} in
+   the `input` chain. Call `create_filter_rule` using Safe Mode.
+
+5. **Verify the session.** Call `list_bgp_sessions` — the session should reach
+   `established` state. If it stays in `connect` or `active`, check:
+   - Firewall rules on both sides.
+   - IP reachability (`ping` {{peer_address}}).
+   - AS number and address-family mismatch.
+
+6. **Check routes.** Call `list_bgp_advertisements` to see what this router is
+   advertising. Call `list_routes` to see BGP-learned routes from the peer.
+
+7. **Routing filters (optional).** If you need to filter incoming or outgoing
+   prefixes, set up routing filter rules to accept/reject specific prefixes.
+
+Report the session status, routes received/advertised, and any warnings.

package/prompts/setup-hotspot.md

@@ -0,0 +1,52 @@
+---
+name: setup-hotspot
+title: Build a captive portal hotspot
+description: Deploy a complete guest hotspot with captive portal, DHCP, per-user bandwidth limits, and optional voucher codes.
+arguments:
+  - name: interface
+    description: The interface for the hotspot (e.g. "wlan1", "ether5", "vlan-guest"). This is where guest clients connect.
+    required: true
+  - name: dns_name
+    description: DNS name for the captive portal (e.g. "hotspot.local"). Optional.
+    required: false
+---
+
+Deploy a complete captive-portal hotspot on this MikroTik device. The hotspot
+will have its own DHCP, gateway, bandwidth limits, and optional voucher-based
+access. Confirm the plan before applying changes.
+
+Hotspot interface: {{interface}}
+Portal DNS name: {{dns_name}}
+
+Steps:
+
+1. **Check the interface.** Call `get_interface` for {{interface}} to confirm it
+   exists and is running. For a wireless interface, verify an SSID is set with
+   `list_wireless_interfaces`.
+
+2. **Build the hotspot.** Call `build_guest_hotspot` with:
+   - The interface ({{interface}}).
+   - A gateway subnet (e.g. 10.5.50.1/24).
+   - DHCP pool for clients.
+   - Per-user bandwidth limits (e.g. 5M download / 2M upload).
+   - The DNS name for portal redirect ({{dns_name}} if provided).
+     This creates the IP address, DHCP server, hotspot instance, and profile in
+     one step.
+
+3. **Generate vouchers (optional).** Call `generate_hotspot_vouchers` to create
+   time-limited or usage-limited access codes. Present the voucher codes in a
+   table with their limits and expiry.
+
+4. **Walled garden.** If the portal needs to allow access to specific sites
+   without login (e.g. a terms page, payment gateway), add walled-garden entries.
+
+5. **Firewall.** Verify the hotspot network is isolated from the management and
+   internal networks — the hotspot setup should handle this, but confirm with
+   `list_filter_rules`.
+
+6. **Test.** Verify the portal redirect works — a client connecting to
+   {{interface}} should be redirected to the login page before getting internet
+   access.
+
+Report the hotspot configuration: gateway, DHCP range, bandwidth limits, voucher
+codes (if generated), and the portal URL.

package/prompts/setup-multi-wan.md

@@ -0,0 +1,46 @@
+---
+name: setup-multi-wan
+title: Set up multi-WAN failover or load balancing
+description: Configure resilient multi-WAN with health-checked active-passive failover or ECMP load balancing across two or more uplinks.
+arguments:
+  - name: wan_interfaces
+    description: Comma-separated WAN interface names (e.g. "ether1,ether2" or "ether1,lte1").
+    required: true
+  - name: mode
+    description: "failover" for active-passive with health checks, or "loadbalance" for ECMP. Default is failover.
+    required: false
+---
+
+Set up multi-WAN resilience on this MikroTik device so it stays online even when
+a link goes down. Confirm the plan with the user before applying changes.
+
+WAN interfaces: {{wan_interfaces}}
+Mode: {{mode}}
+
+Steps:
+
+1. **Inventory the WANs.** Call `list_interfaces` and `list_ip_addresses` to
+   confirm each WAN interface exists, is running, and has an address (static,
+   DHCP, or PPPoE). Note each WAN's gateway.
+
+2. **Deploy the multi-WAN setup.**
+   - For **failover**: call `setup_wan_failover` with the WAN interfaces. This
+     creates health-check routes (pinging reliable targets like 1.1.1.1 and
+     8.8.8.8) and distance-based route priorities — the secondary WAN activates
+     only when the primary's health check fails.
+   - For **load balancing**: call `setup_wan_loadbalance` with the WANs. This
+     creates ECMP routes that spread traffic across both uplinks, with health
+     checks to pull a dead link out of the pool automatically.
+
+3. **Firewall / NAT.** Ensure each WAN has a masquerade/srcnat rule so outbound
+   traffic uses the correct source address. Check `list_nat_rules`.
+
+4. **Verify failover.** Test by temporarily disabling the primary WAN interface
+   and confirming traffic switches to the secondary:
+   - `ping` 8.8.8.8 continuously from the router.
+   - `disable_interface` on the primary WAN, verify ping continues via secondary.
+   - `enable_interface` to restore it.
+   - Check `get_routing_table` to confirm route priorities are correct.
+
+5. **Report.** The WAN priority order, health check targets, failover timing,
+   and NAT rules for each WAN.

package/prompts/setup-ospf-peering.md

@@ -0,0 +1,56 @@
+---
+name: setup-ospf-peering
+title: Set up OSPF dynamic routing
+description: Configure OSPF instances, areas, and interface templates for dynamic route exchange between MikroTik routers.
+arguments:
+  - name: router_id
+    description: The OSPF router ID for this device (e.g. "10.0.0.1"). Typically a loopback or management IP.
+    required: true
+  - name: area
+    description: OSPF area ID (e.g. "0.0.0.0" for backbone, "0.0.0.1" for a stub area). Default is backbone.
+    required: false
+  - name: interfaces
+    description: Which interfaces to run OSPF on (comma-separated, e.g. "ether1,ether2,bridge"). If omitted, you'll be asked.
+    required: false
+---
+
+Configure OSPF dynamic routing on this MikroTik device so it automatically
+exchanges routes with neighboring OSPF routers. Confirm the plan before applying.
+
+Router ID: {{router_id}}
+OSPF area: {{area}}
+Interfaces: {{interfaces}}
+
+Steps:
+
+1. **Inventory.** Call `get_system_identity`, `list_interfaces`, and
+   `list_ip_addresses` to understand the device topology. Call
+   `list_ospf_instances` to check if OSPF is already configured.
+
+2. **Create the OSPF instance.** Call `add_ospf_instance` with:
+   - `router_id={{router_id}}`
+   - Redistribution settings if needed (e.g. redistribute connected, static).
+
+3. **Create the area.** Call `add_ospf_area` with the area ID ({{area}} or
+   `0.0.0.0` for backbone). For stub areas, set `type=stub`.
+
+4. **Add interface templates.** For each interface in {{interfaces}}, call
+   `add_ospf_interface_template` with:
+   - The interface name and area.
+   - Network type (broadcast for Ethernet, point-to-point for tunnels).
+   - Cost if you want to influence path selection.
+   - Authentication if required (MD5 or simple password).
+
+5. **Firewall.** Ensure OSPF traffic is allowed — add a `create_filter_rule` in
+   the `input` chain accepting protocol 89 (OSPF) on the relevant interfaces.
+   Use Safe Mode for firewall edits.
+
+6. **Verify adjacency.** Wait a few seconds, then call `list_ospf_neighbors` to
+   confirm the neighbor relationship reaches `Full` state. If stuck in
+   `ExStart` or `2-Way`, check MTU, area, and authentication match.
+
+7. **Check routes.** Call `list_routes` and filter for OSPF routes to confirm
+   remote subnets are being learned.
+
+Report the OSPF instance, area, interface assignments, neighbor status, and
+learned routes.