However, I am still unsure how or where I am supposed to describe the functionality that a method of a class offers.
In code, I would simply put a docblock above a method in which I describe that method's purpose. Where would I put that information in a UML diagram?
Use good names
UML is a modeling language that is visual, generally more so than source code. However, good naming strategies apply equally to class methods, regardless of representation (UML or source code). A good name captures the "what" of a method. Usually, this name is going to fit well with the name of the class. It's the principle of strong (high) cohesion.
If you use good names, you won't need much explaining! I'd suggest using the source code to comment things like authors who modified the code, dates, etc.
You can apply refactoring to UML models (e.g., sequence diagrams which results in new class diagrams), just as you do with source. Renaming methods as well as extracting methods is a way to make your solution more understandable (and even more reusable). Again, this goes along the lines of high cohesion. Beware, however, that as you refactor, the docblocks you wrote (in text) will not update themselves. It's easy for the solution to become inconsistent with your docblock.
So I am wondering: How would I 'translate' a docblock description into UML?
Docblock descriptions are basically comments. The best way to write comments is a controversial topic in software engineering, since it's very easy for comments to become inconsistent with the code (or the model, if you're using UML).
Sequence diagrams for a method will show the "how" of the method, and are better than any docblock because they're visual and should be consistent with the actual solution. Some UML tools allow generation of sequence diagrams from the source code (or vice versa), so you can see immediately how a method works. However, the quality of this generation is subject to the tool and the complexity of the method.
If your method is really doing something not obvious, a UML note would be a good way to show those things, just as line comments are used in a programming language. Here's an example from Craig Larman's Applying UML and patterns book: