No. If the section beginning "Protocol" is what you refer to as the "actual protocol description" then no, the server role does not seem clearly described in any level of detail.

To cut a long story short: Alice gives the cache, aka Mallory, a set of secret data which are implied but not proven to be able to be used by Bob to create cryptographic text which Alice can decrypt but this magic cache, aka Mallory, cannot. This document provides few hints and no detail on how we can be assured that the magic cache, A.K.A. MALLORY, is unable to make use of the secret data provided by Alice (and "promised not to be shared") to make inferrences on the crypyographic text provided by Bob.

The cache contains ephemeral _PUBLIC_ keys, that would otherwise be transmitted to anyone who requests them by the message recipient (perhaps through some encrypted channel, but without meaningful authentication). In essence it's the same thing as PGP's encryption subkeys, which are completely published, but the cache contains more of them as the keys are preferably only used once (there is one difference in that the cache gives only one key at a time and will not give the same public key again as long as it contains enough of them).

So: making the whole thing completely public only enables adversary to match session initializations with receivers, which the server can do by definition as it has to route the messages to correct recipient. (In the case without such central server, anybody observing the traffic could do that, as another role of the central server is to mask sender addresses on the lower protocol layers)

Good! Say that! Then the entire protocol and its description can be reduced to "this is a cache of ephemeral public keys and messages encrypted using them".

I know that doesn't sound quite so impressive, but that's because it isn't.

Cryptographic protocols are not supposed to be impressive. But on the other hand your shortened description describes the main difference between Signal and traditional OTR, it does not describe how the protocol works after you get the ephemeral key of the receiver.

Additional and to some extent non-trivial difference from traditional OTR is in how these ephemeral keys are used in key exchange, whose result depends not only on DH with ephemeral keys but also on DH exchange that mixes ephemeral keys with long term ones. This causes that the ephemeral key of the passive side does not have to be signed and allows anyone to produce arbitrary session transcripts, both of these points allow significant reduction of size of the exchanged messages.

That was made apparent in their documentation.

Or would have been, if they had any.