The input recipe is just a technical detail of the RTDE communication protocol, you generally don’t need to care or even know about it.
Here is more technical information if you are interested.
The Connectivity feature in VC implements version 1 of the RTDE protocol, which allows reading a wide variety of information from the UR robot controller, and also writing back a more limited set of variables. Which subset of the available information you want to use and for what is up to your use case and simulation setup.
The usual case is reading the current joint values and also binary output values so you can create and test a UR robot program in the context of the 3D simulation environment that VC can provide. This is in contrast to either programming the robot using real hardware, or having to program the robot “blindly” and then probably still need lots of time testing with real hardware.
The Connectivity feature allows free pairing of “server” variables to VC simulation signals, properties, signal maps, and joints. Your simulation logic can then be built to react to changes in any of those, or you could e.g. just collect the values and process them in some way using Python scripts.
Maybe you wanted to e.g. check that TCP speed of the UR robot doesn’t go over some unsafe threshold in your collaborative robot setup?
The vector-form TCP velocity is available from the RTDE interface directly, so you could connect that to e.g. some VC properties and then use a script to calculate the speed and alert you when it goes over your safe limit. This particular thing could probably be implemented on the UR controller side as well, but more complex use cases will benefit more from the VC simulation environment.