Each tool targets a distinct action on a distinct input: mark_file writes a watermark to a file, verify_file inspects an arbitrary file for marks, and get_asset retrieves a stored record by asset_id. The descriptions make the file-path vs asset_id boundary explicit, so misselection is unlikely despite the shared 'record lookup' element in verify_file.

All three tools follow a clean verb_noun pattern (mark_file, verify_file, get_asset) with consistent snake_case. The conventions are predictable enough that a caller can guess naming for any future tool.

Three tools map exactly onto the narrow workflow of write-mark, check-mark, and fetch-record; nothing feels redundant or padded. This sits at the low end of the ideal 3-15 range but is well-matched to a single-purpose watermarking service.

The core lifecycle (mark, verify, retrieve by id) is fully covered with no dead ends for the primary use case. The main gap is the absence of a list/enumerate operation for assets marked by the account, so an agent must persist asset_ids itself; revocation or quota-checking is also absent but less critical.