No user-submitted related servers found.
Scored across 19 tools
The propose_/confirm_ pairing gives each operation a clear dry-run vs apply boundary, and verify_board is repeatedly (and correctly) framed as the single verdict tool, which resolves most confusion. A few pairs still sit close together: propose_input_preparation (moving copper text to silkscreen) vs propose_silkscreen_minimums (resizing text) both operate on the same board text, and the baseline pinning happens implicitly inside confirm_board_rules / confirm_input_preparation as well as in pin_rule_baseline.
The dominant pattern is verb_noun (verify_board, pin_rule_baseline, load_toolset), and the six propose_/confirm_ pairs are perfectly parallel. Deviations are minor but real: project_create/project_open reverse to noun_verb, list_toolsets uses a plural where load_toolset/unload_toolset use singular, and only the pour pair carries a '_step' suffix.
19 tools is on the heavy side, but half of them are the six propose/confirm pairs, which exist so that irreversible board writes require a dry run first — that doubling is justified by the domain rather than redundant. The five orchestration tools (list/load/unload_toolset, pin_rule_baseline, verify_board) and two project tools each carry a distinct role.
The visible surface covers a coherent forward pipeline (scaffold, outline, rules, schematic import, input prep, silkscreen, pour, verify) with no way to undo or remove anything once written. The documented stage order explicitly names 'routing' after the pour step, yet no routing tool appears here — it must come from a dynamically loaded toolset — and there is no export/manufacturing output (gerbers, drill, BOM) or board-inspection tool beyond project_open's summary.