verify_receipt is clearly distinct, but screen_action and check_policy overlap substantially: screen_action already evaluates DLP leakage, policy constraints, and loop prevention, while check_policy checks content/parameters against DLP, sanctions, and loop limits. The descriptions hint that one is a pre-execution authorization gate and the other a narrower guardrail check, but an agent could reasonably select either for the same content-screening need.

All three tools use the same vizier_ prefix followed by a clear verb_noun pattern: screen_action, verify_receipt, check_policy. The convention is predictable and readable throughout.

Three tools is reasonable for a focused runtime security/authorization layer, and each appears to serve a role. It sits at the low end of the typical 3-15 range, with little room for policy management or introspection.

The surface covers the core lifecycle: screen an action, check guardrails, and verify an issued receipt. Minor gaps exist around policy configuration/listing or retrieval of prior receipts, but the essential authorization and audit workflows are present.