Each tool targets a distinct resource+action pair across three clear resource groups (persons, aircraft, manifests), so an agent can pick the right one in most cases. The only soft boundary is between create_manifest_draft and update_manifest, which both touch flight fields and occupants; the descriptions clarify that one creates a new draft and the other mutates an existing manifest, but the split is not as crisp as the rest.

Every tool follows the same snake_case verb_resource pattern (list_persons, get_person, create_person, update_person, list_aircraft, update_aircraft, list_manifests, get_manifest, update_manifest). The only qualifier is the descriptive _draft suffix on create_manifest_draft, which stays within the convention and aids readability.

Ten tools is well-scoped for a domain with three resource types, and each tool maps to a real operation (list/get/create/update) rather than padding. Nothing looks redundant or missing purely for count reasons.

Persons have near-full CRUD but no delete; aircraft only support list and update (no create or get), and manifests lack any delete operation. Submission to CBP/eAPIS is explicitly left as a manual web step, which is a deliberate boundary but still means an agent asking to 'submit a manifest' hits a dead end.