No user-submitted related servers found.
Scored across 23 tools
Core lifecycle tools (init, checkpoint, goal_transition, task_transition, hydrate, prune) are clearly distinct, but the extension cluster is muddled: crystal_extension_call explicitly duplicates crystal_extension_run, and crystal_extension_comms overlaps both, while crystal_extension_manage/list are separate concerns. Additionally crystal_batch is a meta-tool that re-executes the semantics of nearly every other tool, and crystal_search overloads two modes (crystal listing vs DAG node inspection), creating real selection ambiguity.
Nearly all tools use a consistent snake_case crystal_<verb> or crystal_<verb>_<noun> pattern (crystal_triage, crystal_archive, crystal_hydrate, crystal_prune). The extension tools deviate into a crystal_extension_<verb> noun-scoped subgroup, which is a minor but defensible deviation rather than chaotic mixing.
At 23 tools the surface sits in the heavy band for a single-domain server; the five extension tools plus crystal_batch and crystal_extension_call push it past what the core crystal lifecycle actually needs. A few tools (extension_call, batch) feel like escape hatches rather than earned primitives.
The domain is well covered: creation (init), DAG mutation (checkpoint, transitions, melt, slice_fork), retrieval (hydrate, search), lifecycle hygiene (triage, archive/unarchive, prune), artifacts, lessons, stats, lattice bonds, and extensions. Minor gaps exist around crystal metadata update/rename and bulk export, but no workflow dead-ends.