The three tools map to distinct operations: a pre-write conflict check, a write, and a semantic read. amu_check_conflict and amu_search both read from the AMU store, which could momentarily overlap, but their descriptions (exact metric_name/hash match vs. natural-language similarity query) clearly separate them.

All tools share a consistent amu_ prefix and use lowercase snake_case, so the set reads as a coherent family. Minor deviation: amu_check_conflict follows verb_noun while amu_record and amu_search are bare verbs, but this is still readable and predictable.

With only 3 tools the surface is on the lean side, but each tool is well-scoped to a distinct step of the AMU lifecycle (record, retrieve, conflict-check), so nothing feels redundant or padded. It is slightly under-provisioned rather than excessive.

The core write/search/conflict-check loop is covered, but there is no way to fetch or list an AMU by identifier or metric_name outside of a semantic query, and no update/delete path (which may be intentional for immutable, lineage-gated memory). These are notable gaps an agent would hit when trying to enumerate or revisit known AMUs.