What is a Tool-Level Policy?
A tool-level policy targets a specific MCP tool (e.g. create_payment_intent on the Stripe server) rather than an entire server, providing the most granular level of policy enforcement available in Intercept.
WHY IT MATTERS
MCP servers expose multiple tools, each with different risk profiles. A GitHub server exposes both list_repos (read-only, low risk) and delete_repo (destructive, high risk). A server-level policy that allows or denies the entire server is too blunt. Tool-level policies let you make precise decisions: allow listing, deny deletion, log creation.
This granularity maps to how organisations actually think about permissions. A junior developer might be allowed to read files but not deploy. A billing agent might create invoices but not issue refunds above a threshold. Tool-level policies express these nuanced permissions declaratively, without requiring changes to the MCP server or the agent's code.
Tool-level policies can include argument conditions for even finer control. Rather than simply allowing or denying create_charge, you can allow it only when amount < 1000 and currency == "GBP". This layering of tool selection and argument constraints creates a powerful and readable policy language that scales from simple use cases to complex enterprise requirements.
HOW POLICYLAYER USES THIS
In Intercept, tool-level policies are defined as rules within a policy file that specify a tool name or pattern. They take precedence over server-level defaults through the policy inheritance mechanism. Tool-level rules support exact tool name matching, glob patterns (e.g. read_*), and can include any number of argument conditions. When multiple tool-level rules could match, policy priority determines which one applies.