/waf-rules

name: webflow-mcp:waf-rules
description: Review and change a Webflow site's Web Application Firewall (WAF) rules and Bot bypass settings through Webflow MCP. Use when the user wants to block or allow countries, IP addresses or CIDR ranges, networks (ASNs), bots, AI crawlers, scrapers, or User-Agents, optionally only on some paths; add, edit, or remove firewall or WAF rules; enable or disable Bot bypass; review or explain the current rules; or draft rules from findings about unwanted traffic. Changes are previewed and confirmed by the user before they reach live traffic. Needs an Enterprise plan that includes WAF, and WAF MCP must be enabled for the workspace.

WAF Rules

Review and change the Web Application Firewall (WAF) rules and Bot bypass settings Webflow enforces on a site's connected custom domains. Changes reach live traffic without a site publish and can lock out real visitors, so validate rule configs, preview changes, and get user confirmation first.

Important Note

**ALWAYS use Webflow MCP tools for all operations:**

• Use Webflow MCP's `webflow_guide_tool` before any other tool call
• Use Webflow MCP's `data_sites_tool` with action `list_sites` to find the site
• Use Webflow MCP's `data_enterprise_tool` with these WAF actions. Each takes `site_id`.
• `get_waf_rules`: current rules per domain and the `siteStateHash`
• `validate_waf_rule`: checks a candidate config and explains it in plain language. Changes nothing.
• `test_waf_rules`: previews an update or deletion and returns a `previewToken`. Changes nothing.
• `update_waf_rule`, `delete_waf_rule`: write the live firewall
• `test_waf_settings`: previews Bot bypass settings and returns a `previewToken`. Changes nothing.
• `update_waf_settings`: writes the live Bot bypass settings
• `suggest_waf_changes`: proposes rule changes and applies none. Read-only.
• DO NOT call the Webflow API directly or use any other tool to change WAF rules or settings
• Include the `context` parameter when the tool schema asks for it (15-25 words, third-person perspective)

Before You Start

The API refuses a call by name when one of these is missing (see Errors):

• **Enterprise plan:** WAF MCP needs an Enterprise plan that includes WAF.
• **WAF MCP enabled for the workspace:** WAF MCP is rolling out, so if `data_enterprise_tool` doesn't list the WAF actions, or a call returns `waf_mcp_not_enabled`, it isn't enabled for the workspace yet. Tell the user. They can still manage rules in the Dashboard under Site settings > Security.
• **Settings action availability:** discover the `data_enterprise_tool` action schema before offering a settings change. If `test_waf_settings` or `update_waf_settings` is absent, say Bot bypass changes are unavailable through this connection and point to Dashboard > Site settings > Security. Don't claim success or try to change settings through a rule config.
• **Role:** the user must be able to manage the site's custom domains: Site manager, Designer, Limited designer, or a custom role with that permission. Designer (needs approval), Marketer, Content editor, and Reviewer can't.
• **Scopes:** `site_config:read` for reads and `validate_waf_rule`, `site_config:write` for `test_waf_rules`, `update_waf_rule`, `delete_waf_rule`, `test_waf_settings`, and `update_waf_settings`. The Webflow MCP app requests both. If a call returns `missing_scopes`, the user has to reauthorize the connection.

Instructions

Phase 1: Read the current rules

1. Call `webflow_guide_tool`. When WAF MCP is enabled, it includes a WAF section. 2. Resolve the site with `list_sites`. If the user didn't name one, or the name matches several, ask. 3. Call `get_waf_rules` and keep:

• `byDomain`: each connected custom domain's config, or `null` when it has none. A config holds up to four rule types (`ipRules`, `geoRules`, `asnRules`, `userAgentRules`) plus the bot bypass settings.
• `uniform`: true when every domain has the same config. `rules` then holds it.
• `hostnamesSkipped`: connected domains WAF can't apply rules to yet.
• `siteStateHash`: all rule and settings previews and writes require it as `expectedSiteStateHash`. Read again before each change; a hash from an earlier read is refused with `WafSiteStateChanged`.

4. If the user asked for a review or an explanation, follow "Reviewing rules" and stop. A review doesn't authorize a change. For Bot bypass changes, follow "Changing Bot bypass settings" instead of Phases 2–4.

Phase 2: Build and validate the change

5. Change one rule type at a time. An update replaces that rule type's **entire** config on its target domains, and any entry left out is removed. Copy the current config from `byDomain[domain][ruleType]`, apply the user's edit, and keep every other entry in its order. Leave `bypassVerifiedBots` and `bypassAuthorizedBots` out: they're settings, not part of a rule type. 6. Choose the scope (see "Domain scope"): site-wide when the change is for every domain and they share the current config, otherwise `domains` plus `previousDomains`. 7. Call `validate_waf_rule` with `ruleType`, `config`, and the `domains` and `previousDomains` you plan to use. It's read-only and needs no hash, so call it as often as needed.

• `success: false` with `ValidationError`: fix the config from `error.details` (field path and message) and `error.schema` (the JSON Schema for the rule type, present when the shape itself is wrong). Cross-field user-agent rules appear only in `details`. Validate again. If an entry that's already live is what fails (older rules can predate today's checks), tell the user instead of dropping or rewriting it silently.
• `success: true`: read every `explanation` line and check it against what the user asked for. If it describes anything they didn't ask for, such as "blocks every other country", fix the config or ask. Use the normalized `config` it returns from here on.
• Non-empty `riskFindings`: tell the user now that applying will n