--- name: azion-create-rules-engine-rules-with-the-mcp-server description: >- Ask a coding agent connected to the Azion build MCP server to preview a Rules Engine rule with dry_run, review the request, and create the rule. --- # Create Rules Engine rules with the MCP server You can create a [Rules Engine](/en/documentation/platform/applications/rules-engine/) rule by describing it to a coding agent connected to the build server of the [Azion MCP servers](/en/documentation/devtools/mcp/). The build server writes to your account, so the agent first calls the tool with `dry_run`, which returns the API request without sending it. You review that request, and then the agent sends it. For the same rule built by hand in Azion Console, follow [Create an application rule](/en/documentation/guides/application-development/getting-started/work-with-rules-engine/). --- ## Prerequisites - A coding agent connected to the build server, `https://build-mcp.azion.com/mcp`. To connect one, refer to [MCP server quickstart](/en/documentation/devtools/mcp/quickstart/). - A personal token with permission to change the application. The build server sends every request with this token. - The ID of the application to add the rule to. --- ## Create a rule with your agent The build server creates a request rule with `create_request_rule` and a response rule with `create_response_rule`. Both take the `application_id`, a `name`, the `criteria`, and the `behaviors` of the rule. To create a rule that redirects an old path: 1. **Describe the rule and ask for a preview** Give the agent the application ID, the goal, and the instruction to preview the request first. For example: ```text In application 1234567890, create a request rule that redirects every URI starting with /old-blog/ to https://www.example.com/blog/ with a 301. Preview it with dry_run before you create it. ``` 2. **Review the preview** The agent calls `create_request_rule` with `dry_run` set to `true`. The tool returns the request it would send to the [Azion API](/en/documentation/devtools/api/), and sends nothing: ```json { "dryRun": true, "request": { "method": "POST", "url": "https://api.azion.com/v4/workspace/applications/1234567890/request_rules", "headers": { "Accept": "application/json", "Content-Type": "application/json", "X-Azion-Resource-Indicator": "urn:azion:mcp:unknown", "Authorization": "Token [TOKEN VALUE]" }, "body": { "name": "Redirect old blog", "criteria": [ [ { "conditional": "if", "variable": "${uri}", "operator": "starts_with", "argument": "/old-blog/" } ] ], "behaviors": [ { "type": "redirect_to_301", "attributes": { "value": "https://www.example.com/blog/" } } ], "active": true } } } ``` Check the `url`, which names the application and the phase, and the `body`, which is the rule. The preview shows the `Authorization` header with your full personal token, so never share a preview without removing it. 3. **Ask the agent to create the rule** When the request is what you want, ask the agent to repeat the call without `dry_run`. The build server sends the request with your token, and the rule exists in the application from then on. 4. **Check the rule** Ask the agent to list the request rules of the application. `list_request_rules` returns each rule with its `id`, `name`, `active` state, and `order`. The new rule appears in the **Rules Engine** tab of the application, in the list of its phase. To change the order in which rules run, ask the agent to call `reorder_request_rules` or `reorder_response_rules`. --- ## Read the fields of a rule The inputs of `create_request_rule` follow the rule shape of the Azion API v4: - **`criteria`**: an array of one to five groups, each with one to ten criteria. A criterion carries a `conditional` (`if`, `and`, or `or`), a `variable` such as `${uri}`, an `operator` such as `starts_with` or `matches`, and an `argument`. For every operator, refer to [Operators](/en/documentation/platform/applications/rules-engine/#operators). For how criteria combine, refer to [Conditionals](/en/documentation/platform/applications/rules-engine/#conditionals). - **`behaviors`**: an array of one to ten behaviors. A behavior `type` is lowercase, such as `redirect_to_301` or `set_cache_policy`, and a behavior that takes an argument carries it in `attributes.value`. - **`active`**: whether the rule runs, `true` by default. - **`description`**: optional text of up to 1,000 characters. `${request_uri}` requires [Application Accelerator](/en/documentation/platform/applications/application-accelerator/settings/) on the application. Without it, match `${uri}` instead, as [Variables](/en/documentation/platform/applications/rules-engine/#variables) explains. --- ## Create a cache setting and the rule that applies it A `set_cache_policy` behavior applies a cache setting, which holds the TTL, and its `attributes.value` is the ID of that cache setting. Create the cache setting first. For example, to cache images for a day: 1. **Preview the cache setting** Ask the agent to create a cache setting with a one-day cache TTL and a one-hour browser TTL, and to preview it with `dry_run`. The agent calls `create_cache_setting`, and the `body` of the preview is the cache setting: ```json { "name": "images-1-day", "browser_cache": { "behavior": "override", "max_age": 3600 }, "modules": { "cache": { "behavior": "override", "max_age": 86400 } } } ``` A `max_age` in `modules.cache` below `60` requires Application Accelerator on the application. 2. **Create the cache setting** Ask the agent to repeat the call without `dry_run`, and to give you the ID of the new cache setting. 3. **Create the rule that applies it** Ask the agent for a request rule whose criterion matches the image paths and whose behavior is `set_cache_policy`, with the cache setting ID in `attributes.value`. Review the `dry_run` preview, then create the rule. Create the rule as a request rule. *Set Cache Policy* runs only in the Request Phase, as [Set Cache Policy](/en/documentation/platform/applications/rules-engine/#set-cache-policy) states. When one goal needs two cache settings, such as one TTL for static assets and one for `/api/`, create one rule per criterion, each with its own cache setting. A single rule with both criteria joined by `or` applies both behaviors to both kinds of request. --- ## Create a firewall rule A rule for [Rules Engine for Firewall](/en/documentation/platform/firewall/rules-engine/) belongs to the secure server, `https://secure-mcp.azion.com/mcp`, not to the build server. Connect it, then ask the agent for the rule. The agent calls `create_firewall_rule`, which also takes `dry_run`. To change the order of firewall rules, the agent calls `reorder_firewall_rules`. Every rule the agent creates is also reachable without it: through Azion Console, as [Create an application rule](/en/documentation/guides/application-development/getting-started/work-with-rules-engine/) describes; through the API, as the [API](/en/documentation/platform/applications/rules-engine/#api) section of Rules Engine for Applications describes; or from a JSON file, with [Azion CLI rules-engine](/en/documentation/devtools/cli/resources/rules-engine/). When the agent lists no `create_request_rule` tool, the build server is not connected; [Troubleshoot the MCP server](/en/documentation/devtools/mcp/troubleshooting/) covers the fix. --- ## Next steps - [Rules Engine for Applications](/en/documentation/platform/applications/rules-engine.md): Every rule field, variable, operator, and behavior, with the phase each one accepts. - [Create an application rule](/en/documentation/guides/application-development/getting-started/work-with-rules-engine.md): Create a rule in Azion Console, from its criteria to its behaviors. - [Create a cache setting](/en/documentation/guides/application-performance/cache-and-purge/tune-cache-settings.md): Set the TTL that a Set Cache Policy behavior applies to requests. - [Tools and resources](/en/documentation/devtools/mcp/tools.md): The rule, cache, and purge tools of the build server, and the inputs every server shares.