This is a question of documentation, not type design. You don't have to consider what exceptions your transitive dependencies might throw—you need to understand what inputs *do* cause your function to fail. If you use head in a safe way or have a call to error in an unreachable case, you shouldn't say anything. On the other hand, if your function fails when the inputs aren't relatively prime, you should document this regardless of whether the failure is an exception you throw explicitly, a result of a partial pattern match or a division by zero four layers of indirection away.
I definitely expect the author of a function to understand what inputs cause that function to fail. If you don't understand this, you simply don't understand the code you wrote. (Luckily, QuickCheck will probably find any edge cases you missed when writing the function.)
Thinking about it a bit more, there's nothing specific to exceptions here. If your code loops forever when the lengths of the inputs sum to a multiple of seven, that's pretty handy to know from the documentation!
I would also expect the same style of documentation even for errors expressed in the types with whatever your favorite generalization of Either happens to be.