Yes, I think that's the right next layer. On a lot of real APIs the risky part lives in the body, not the path. A messaging API where the same call drafts or sends. A payment call with a capture flag. A bulk update whose filter happens to match every record.
Two things I'd watch. First, default-deny on fields the rule doesn't know about, so a new argument can't slip through. Second, let rules check values, not just whether a field is present. Amount over a limit, recipient outside an allowlist, an empty filter. That's where most of the "in policy but still wrong" actions live.
For MCP I'd also let the tool author tag each action as read, write, or irreversible, and treat anything untagged as irreversible. Then argument rules are the override, not the only line of defense.
Two things I'd watch. First, default-deny on fields the rule doesn't know about, so a new argument can't slip through. Second, let rules check values, not just whether a field is present. Amount over a limit, recipient outside an allowlist, an empty filter. That's where most of the "in policy but still wrong" actions live.
For MCP I'd also let the tool author tag each action as read, write, or irreversible, and treat anything untagged as irreversible. Then argument rules are the override, not the only line of defense.