memory_lint audits an existing store for duplicates, contradictions and staleness, while memory_admit gates a single incoming fact before it is written. These are clearly different phases (bulk audit vs. write-path check), so misselection is unlikely, though both are 'inspect memory' operations and could blur for an unfamiliar agent.

Both tools use the same predictable memory_<verb> snake_case pattern (memory_lint, memory_admit) with no style mixing. Naming is fully consistent and readable.

Two tools is on the thin side even for a narrow domain; lint and admit cover the two documented entry points but leave little room for related operations the domain implies (review queue, applying edits). Borderline but not egregiously mismatched.

The pair covers an audit pass and a write gate, but there are dead ends: memory_admit returns a supersede edit and a requires_review state with no tool to apply the edit or resolve queued review items, and no retrieval/update surface for stored memories. Notable missing operations, though the core two stages are present.