@usex/mikrotik-mcp 3.51.1 → 3.52.0

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.

package/prompts/setup-port-knocking.md

@@ -0,0 +1,53 @@
+---
+name: setup-port-knocking
+title: Hide management behind port knocking
+description: Conceal SSH/Winbox/API behind a secret port-knock sequence that temporarily opens access from the knocking IP.
+arguments:
+  - name: services
+    description: Which services to protect (comma-separated, e.g. "ssh,winbox,api"). Default is SSH and Winbox.
+    required: false
+  - name: knock_ports
+    description: Comma-separated port sequence for the knock (e.g. "1234,5678,9012"). If omitted, random ports are chosen.
+    required: false
+---
+
+Set up port knocking on this MikroTik device to hide management services behind a
+secret port sequence. Only IPs that complete the knock sequence get temporary
+access — everyone else sees the ports as closed.
+
+Services to protect: {{services}}
+Knock port sequence: {{knock_ports}}
+
+Steps:
+
+1. **Check current access.** Call `list_ip_services` to see which management
+   services are enabled. Call `list_filter_rules` with `chain=input` to review
+   existing access rules.
+
+2. **Set up the knock sequence.** Call `setup_port_knock` with the services to
+   protect and the port sequence (or let it generate random ports). This creates:
+   - Firewall address-lists that track the knock progress per source IP.
+   - Filter rules that move an IP through the stages as it hits each port.
+   - A final rule that allows access to the protected services for IPs that
+     complete the full sequence (with a timeout, typically 15 minutes).
+   - A drop rule for the protected services from all other IPs.
+
+3. **Verify the knock.** Test that:
+   - Without knocking, the protected ports are unreachable.
+   - After sending packets to the knock ports in order, access opens.
+   - After the timeout, access closes again.
+
+4. **Document.** Present the knock sequence clearly so administrators can save it
+   somewhere secure. Include example commands to knock from a client:
+
+   ```
+   nmap -Pn --host-timeout 100 -p PORT1 ROUTER_IP
+   nmap -Pn --host-timeout 100 -p PORT2 ROUTER_IP
+   nmap -Pn --host-timeout 100 -p PORT3 ROUTER_IP
+   ```
+
+5. **Safety warning.** Remind the user to keep a backup access method (e.g.
+   MAC-Telnet from a local network, or a trusted IP that bypasses the knock)
+   to avoid being locked out.
+
+Do not apply changes without user approval.

package/prompts/setup-threat-feeds.md

@@ -0,0 +1,47 @@
+---
+name: setup-threat-feeds
+title: Subscribe to threat intelligence feeds
+description: Import external threat-intel IP blocklists into firewall address-lists with automatic scheduled updates.
+arguments:
+  - name: feed_url
+    description: URL of the threat feed (one IP per line). If omitted, a well-known public feed will be suggested.
+    required: false
+  - name: list_name
+    description: Firewall address-list name to populate (e.g. "threat-blocklist"). Default is chosen automatically.
+    required: false
+---
+
+Subscribe this MikroTik device to an external threat intelligence feed that
+automatically imports malicious IPs into a firewall address-list and keeps it
+updated on a schedule.
+
+Feed URL: {{feed_url}}
+Address-list name: {{list_name}}
+
+Steps:
+
+1. **Choose the feed.** If {{feed_url}} is not provided, suggest a well-known
+   public feed (e.g. Spamhaus DROP, Emerging Threats, or abuse.ch). Explain what
+   the feed contains and its update frequency.
+
+2. **Subscribe.** Call `subscribe_threat_feed` with the feed URL and address-list
+   name. This creates a scheduled script that periodically fetches the feed and
+   imports the IPs into the specified address-list.
+
+3. **Verify the import.** Call `list_address_lists` and check that the list exists
+   and contains entries. Report the count.
+
+4. **Create firewall rules.** Add drop rules referencing the address-list:
+   - `create_filter_rule` in the `forward` chain: drop traffic with
+     `src-address-list={{list_name}}` or `dst-address-list={{list_name}}`.
+   - `create_filter_rule` in the `input` chain: drop incoming connections from
+     the list.
+     Use Safe Mode (`enable_safe_mode`) before adding firewall rules.
+
+5. **Confirm the schedule.** Call `list_schedulers` to verify the update script
+   is scheduled (e.g. every 6 or 24 hours).
+
+6. **Report.** The feed URL, address-list name, number of entries imported,
+   firewall rules created, and the update schedule.
+
+To remove a feed later, use `remove_threat_feed`.

package/prompts/setup-vlan-network.md

@@ -0,0 +1,47 @@
+---
+name: setup-vlan-network
+title: Design and deploy VLAN segments
+description: Create isolated VLAN segments with gateway addressing, DHCP, and inter-VLAN firewall policy — previewed before apply.
+arguments:
+  - name: vlans
+    description: Describe the VLANs you need — e.g. "management=10, staff=20, IoT=30, guest=40" (name=VLAN-ID).
+    required: true
+  - name: trunk_interface
+    description: The interface to use as a VLAN trunk (e.g. "ether1", "bridge"). If omitted, the main bridge is used.
+    required: false
+---
+
+Design and deploy a VLAN-segmented network on this MikroTik device. Each VLAN
+gets its own subnet, gateway IP, DHCP server, and firewall isolation. All changes
+are previewed before applying.
+
+VLANs requested: {{vlans}}
+Trunk interface: {{trunk_interface}}
+
+Follow these steps — confirm the plan before applying any changes:
+
+1. **Understand the current layout.** Call `list_interfaces`, `list_bridges`,
+   `list_ip_addresses`, and `list_dhcp_servers` to understand what exists.
+
+2. **Design each VLAN segment.** For each VLAN in {{vlans}}, call
+   `design_network_segment` in **preview mode** with:
+   - VLAN ID and name.
+   - A subnet (auto-assigned or specified — e.g. 10.10.{vlan_id}.0/24).
+   - Gateway address (.1 in the subnet).
+   - DHCP pool range.
+   - Isolation policy (whether this VLAN can reach others).
+
+3. **Review the plan.** Present a summary table:
+   - VLAN ID, name, subnet, gateway, DHCP range.
+   - Firewall rules that will be created for inter-VLAN isolation.
+   - Bridge/trunk configuration changes.
+
+4. **Apply.** With user approval, run `design_network_segment` again with apply
+   mode for each VLAN.
+
+5. **Verify.** Call `list_vlan_interfaces` to confirm VLANs are created,
+   `list_ip_addresses` for gateway IPs, `list_dhcp_servers` for DHCP, and
+   `list_filter_rules` for the isolation firewall rules.
+
+Report the complete VLAN map and any follow-ups (e.g. switch port VLAN
+assignments, wireless SSID-to-VLAN mappings).