PartForge

The core operations are clearly separated by resource and action (read_part_files/search_part_files vs read_reference_part/search_reference_parts, docs vs code vs rendering). The main confusion comes from the trio of viewer_* tools, which are included in the set yet explicitly marked 'not a tool for the assistant', plus mild overlap between get_authoring_guide and the search_docs/read_docs pair. The verbose descriptions do enough to keep an agent from misselecting in practice.

Almost every tool follows a clean snake_case verb_noun pattern (create_forge, get_forge, list_forges, publish_forge, read_part_files, search_reference_parts). The only deviation is the viewer_* family, which uses a noun-first 'viewer_' namespace prefix rather than a verb. That is a single, systematic exception rather than chaos.

At 21 tools the set sits in the heavy band, and three of them (viewer_forge_status, viewer_keep_settings, viewer_load_forge) are internal viewer plumbing the assistant is told never to call, so the effective agent surface is about 18. For a domain with code editing, docs, reference search, rendering, publishing and issue reporting that is defensible, but it is still borderline padded.

The lifecycle is broad: create, read, edit, list, name/describe, publish, unpublish, view, render, plus docs and reference-part research and a feedback channel. The notable gap is deletion or archiving of a forge, and there is no duplicate/fork operation. Minor gaps an agent can work around, but not a fully closed lifecycle.