The short answer is: probably yes.
The long answer is:
Thanks for providing the EIP link. It mentions zipcode and state, which modifies the content of a message.
I’m usually not too happy with message mutators actually modifying the content of a message. I’ve used them before to modify or add headers on some occasions. If integrating with external parties, like brokers like BizTalk do, then this could be a necessity. With brokers like that, we have something in the middle that receives messages from things, transforms them (from XML to JSON, modifies zipcode, etc) and sends them to another thing.
With NServiceBus that’s different. There is nothing in the middle. You’d build either a mutator on the sender side, or on the receiver side. If they are already aware of the transformation, why build this into a message mutator, which is kind of hidden away? Why not make it explicit and put this inside the handler. Obviously, a call to some class, inside a handler. This assumes it’s some transformation like a zipcode. I am not aware of any specific requirements that you have.
That would mean the responsible endpoint defines a contract and doesn’t really care about what others do with its message. In the case of a command (sending a message) the receiver is the one responsible for defining the contract. In the case of an event (publishing a message) the publisher is the one responsible.
Does that make sense?