What is a Policy Condition?

Without conditions, policies are limited to binary allow/deny decisions per tool. This is rarely sufficient. Consider a Stripe MCP server: you want agents to create charges (that is the whole point), but not unlimited charges. You want them to refund orders, but only within 30 days. You want them to update customers, but not change billing addresses. Conditions make these nuanced policies expressible.

Conditions operate on the arguments passed to an MCP tool call. Every MCP tool defines its expected arguments (amount, currency, file_path, branch, etc.), and conditions evaluate these values against constraints before the call reaches the server. This is fundamentally different from output filtering — the tool call never executes if the condition fails.

The condition language is deliberately simple: comparison operators (==, !=, <, >, <=, >=), string matching (contains, starts_with, matches), existence checks (exists, not_exists), and boolean combinators (all, any). This covers real-world policy needs without the complexity and security risks of a full expression language. If you can state the constraint in plain English, you can almost certainly express it as a condition.

Intercept evaluates conditions against the JSON arguments of each MCP tool call. Conditions are defined inline within policy rules and support dot-notation for accessing nested argument fields (e.g. metadata.environment). Multiple conditions on a single rule are combined with AND logic by default — all must pass for the rule to match. Intercept validates condition syntax at policy load time and reports errors with the offending rule and line number.