The three tools occupy genuinely different modes: auditing a config artifact (API key scopes), statically checking a code snippet, and explaining a concept. The one soft edge is between check_idempotency_pattern and explain_guard_pattern, since 'idempotency_key' is also one of the explainable patterns, so an agent asking about idempotency could plausibly reach for either first.

All three follow a clean verb_noun snake_case pattern (audit_api_keys, check_idempotency_pattern, explain_guard_pattern) with unambiguous, domain-specific nouns. The verbs also accurately signal the mode of each tool: audit vs check vs explain.

Three tools is on the thin side but defensible for a tightly scoped 'guard checks' server where each tool maps to one clear input type (key entries, code, pattern name). No padding or redundancy, though the surface feels minimal enough that additional coverage seems intended rather than optional.

The tool set is asymmetric: explain_guard_pattern advertises six patterns (idempotency_key, approval_gate, outbox, key_inventory, circuit_breaker, signed_approval_link) but only idempotency has a corresponding verification tool, and key_inventory is only partly covered by audit_api_keys. An agent can learn about approval gates and outboxes but has no way to check them, creating dead ends in the advertised workflow.