A DSC pull server can actually contain two components: the pull server bit, plus what Microsoft is presently calling a "compliance server." That name will likely change, but it's a good placeholder for now.
In short, the compliance server maintains a database (which it shares with the pull server piece) that lists all of the computers that have checked in with the pull server, and shows their current state of configuration compliance - that is, whether or not their actual configuration matches their desired configuration. So, part of the LCM's job is to not only grab configuration MOFs from the pull server, but also to report back on how things are looking.
You can then generate reports from that database, showing you what nodes are compliant and which ones aren't. Remember that the LCM can be configured to _not continually apply configurations - _we covered that earlier with its ConfigurationMode setting, which can be set to ApplyAndMonitor. In that mode, the LCM can let you know which machines are out of compliance, but not actually do anything about it.
Note that the LCM will only report back if you're using an HTTP(S) pull server; this trick won't work with an SMP pull server.
It's still early days for this particular aspect of DSC, so we'll expand this section of the guide once there's more information from Microsoft on this feature.