Interface Segregation Principle and Convenience/Helper Methods

How does the Interface Segregation Principle apply to convenience/helper methods? For instance:

I want to create an interface that represents business partners. The bare minimum that I would need would be a setter and a getter method that would set or get the entire list of partners:

Interface Partners {
  method getList();
  method setList();
}

I also want to have a contains() method to tell me if a certain person was included in the list of partners. I consider this a helper or convenience method, because all it does it call getPartners() and then check if the given person is in that list.

My understanding of the Interface Segregation Principle is that I should separate my contains() method into a separate interface, since someone might want to implement my Partners interface without providing an implementaiton for this unnecessary helper method. In my example, its not a big deal, but the list of helper methods can quickly grow long (addPartner, addPartnerByID, addPartnerByUserid, etc.), so this is a practical problem.

My concern is that I'm finding it quite difficult to pick a name for an interface to hold my contains() method that does not sound cumbersome, and I think any time you have this much trouble naming something, it is a red flag that there is something wrong in your design. It does not seem right to have an interface named PartnersSupportingSetInclusionChecks, nor does it seem good to have an interface just named PartnerHelperMethods.

How do I apply the Interface Segregation Principle to such methods?