CloudCrane

Most tools target a clearly distinct resource+action, and descriptions explicitly disambiguate the tricky pairs (get_app includes code vs get_spec without it; publish_app for code vs publish_spec for a spec; update_app vs update_spec). The remaining overlap is check_publish versus publish_app, since publish already runs the same checks and the dry-run distinction is only implicit, but the descriptions make it recoverable.

Every tool follows the same snake_case verb-first pattern: get_*, list_*, publish_*, update_*, plus delete_app, rename_app, rollback_app, find_in_app, check_publish. The noun vocabulary (app, spec, remix, version, publish) is reused consistently across verbs, so the naming predicts behavior well.

At 16 tools it is slightly above the comfortable 3-15 band, but the surface is symmetric and each tool maps to a real operation in the app lifecycle. The spec/code duality means two parallel pipelines, which justifies most of the extra tools rather than padding.

The lifecycle is well covered: publish, read, update, rename, rollback, delete, list apps/versions, search code, plus the full spec pipeline and remix read/publish path. Minor gaps remain: no way to delete or prune an individual version, no way to dismiss or remove an unused remix entry, and no tool for managing instalments beyond the link returned at publish.