Most tools map to a unique resource+action (package inspect/extract/build, tuning search/read, STBL creation, script build, live bridge, exception analysis). A few boundaries blur: `build_package` already handles .stbl.json while `create_stbl_dictionary` also writes STBL resources, and `compile_tuning_with_simdata` overlaps conceptually with package building and `query_tdesc_schema`'s starter XML. `hash_fnv` also partially duplicates the hashing inside `create_stbl_dictionary`, but descriptions make the intended split workable.

Nearly all tools follow a snake_case verb_noun pattern (inspect_package, build_package, search_vanilla_tuning, validate_and_build_ts4script). The main deviation is `bridge_send_command`, which uses noun_verb ordering, plus the short `hash_fnv` which names the algorithm rather than a clear object. Still highly readable and predictable overall.

At 17 tools this is on the heavy side, but the surface spans genuinely different workflows (package I/O, tuning index/search, STBL, SimData compile, Python API exploration, live bridge, crash triage). Each tool appears to earn its place rather than being a near-duplicate, though a few could conceivably be folded together.

The modding lifecycle is well covered: index building, vanilla tuning discovery, schema lookup, XML validation, SimData compile, STBL creation, package build/extract, script bundling, and crash analysis. Gaps remain around mutating existing packages (only inspect/extract, no add/remove/replace resource), and `bridge_send_command` has no companion for reading bridge responses, which limits round-trip debugging.