Ask yourself the question "what is this class's single purpose?". Without adhering to Single Responsibility Principle, naming classes and methods becomes very difficult. If you can't answer that question, you may need to re-think what you want the class to do, and consider separating the concerns. This will make it easier to name
Do you have a pattern for how you name your classes? Perhaps try looking at some common naming patterns, for example the pattern, which becomes a lot easier to follow once you've addressed SRP above. Does your class parse XML? Try XMLParser. Does it parse XML, create domain models to represent the input, persist them to the DB and then post a success message to Twitter? Try refactoring.
I understand where you're coming from, and have been in a similar situation before. Perhaps try fleshing out your class with some functionality, with a temporary name to begin with. With any good IDE or refactoring assitant, renaming the class should be a one-click action, so what you name your class initially doesn't need to be permanent! This will both help you get past your OCD-block, and give your subconscious time to process it a bit further.
Finally and slightly off topic
I had a lightbulb moment in some work I was doing the other day, implementing a non-critical system, and I was spending a fair time playing around with different namings of classes etc... Name your interfaces according to the functionality, name your classes according to their specific implemntation... For example, you might be tempted to have IXMLParser and XMLParser, but what happens when your input changes to JSON? Try IInputParser instead, that way you can create concrete classes XMLParser and JSONParser which both implement IInputParser in different ways.