It describes the monitor, not the movie
This is the distinction that makes ST 2086 confusing at first. MaxCLL and MaxFALL measure the content. ST 2086 measures the equipment: what the colourist was actually looking at when they approved the grade.
A display receiving it can reason about intent. If the content was graded on a 1,000-nit monitor covering DCI-P3, and the receiving panel does 600 nits over a similar gamut, the gap is known and the tone-mapping can be conservative. Without it, the display is guessing.
What it contains
Six chromaticity coordinates for the red, green and blue primaries, two for the white point, and two luminance values for the display's minimum and maximum. Ten numbers, sent once.
Together with the rest
ST 2086 plus MaxCLL and MaxFALL is the full static metadata set an HDR10 file should carry. All of it is optional in the sense that players cope without it, and all of it is worth preserving: it lives in the HEVC stream's SEI messages, which is why re-encoding an HDR file destroys it and remuxing does not.
That last point has a practical consequence. Any operation on a finished HDR10 file that re-encodes rather than copies the video stream will strip this metadata unless it is explicitly carried across. See what the converter outputs.
Questions people ask
Do I need mastering display metadata for a file to be HDR?
No. A file with BT.2020 primaries, the PQ curve and 10-bit depth is HDR without it, and players handle its absence. It improves how a display reasons about intent rather than deciding whether the file works.
Why does re-encoding lose it?
Because it lives in the HEVC stream's SEI messages, not in the container. Any operation that re-encodes the video discards those messages unless the tool regenerates them deliberately. Remuxing with a stream copy preserves them, which is why editing a finished HDR file should avoid transcoding.