What is a Tool-Level Policy?

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.

In PolicyLayer, 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.