We cannot query on it as it is not supported by the protocol. However we can do something about it. I tried to maintain the uci protocol and added an issue with the following proposal.
Proposal 1
Support the command optionvalues. This command is sent to the engine.
Some examples on engine reply format.
option name Threads value 2
option name Ponder value true
option name EvalFile value mynn.nnue
Feel free to post, comment or add your proposal in that repo.
I will inform the engine programmers community about this issue as well, so that they can support this on their engine.
By the way this is the usage of uci command.
* uci
Tells the engine to use the uci (universal chess interface),
this will be sent once as a first command after program boot
to tell the engine to switch to uci mode.
After receiving the uci command the engine must identify itself with the "id" command
and send the "option" commands to tell the GUI which engine settings the engine supports if
any. After that the engine should send "uciok" to acknowledge the uci mode. If no uciok is sent
within a certain time period, the engine task will be killed by the GUI.
What is your use case why you query the current engine optionsoption values? From a gui's perspective, it can store option values that it sent to the engine.