1. what is this class supposed to do (and what things isn't)
This should be fairly obvious by name. And if you are good about your 'one class handles one task' it's even better.
Sure, sometimes things need to push the envelope or can't have a great name due to their... generalness. Then make a comment describing what's going on, but realize that the need to make a comment is a code smell.
2. who is supposed to call it, and with what kind of parameters (nothing exhaustive)
Protection level enforces who can call it, and your parameters have descriptive types/names to make the calling convention obvious.
3. maybe explain how it does it if it takes some unexpected approach to optimize it or something like that
Certainly. This is the case where comments are most valuable (in addition to loom_weaver's 'don't do this or else' or 'bug 4255 was caused by this being ___'). Cases where you divert from coding norms for a good reason. Comments exist to supply reasons to code, not to describe code.