An issue at work came up where it was necessary to balance shards to alleviate disk pressure. For the size of our cluster, /_cat/indices  returns close to a thousand lines. Looking at this resulted in me finding that most, if not all, of the cat endpoints do not have uri search  capabilities. This makes finding the data we need difficult in day-to-day tasks.
Unfortunately, I do not have a meaningful examples other than current documentation
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open twitter u8FNjxh8Rfy_awN11oDKYQ 1 1 1200 0 88.1kb 88.1kb
green open twitter2 nYFWZEO7TUiOjLQXBaYJpA 1 0 0 0 260b 260b
I would like to answer questions like
what are the shards on a node?
which shards are currently being transferred?
i s t ty st shost thost f fp b bp
twitter 0 1252ms peer done 192.168.1.1 192.168.1.2 0 100.0% 0 100.0%
index shard time type stage source_host source_node target_host target_node repository snapshot files files_recovered files_percent files_total bytes bytes_recovered bytes_percent bytes_total translog_ops translog_ops_recovered translog_ops_percent
twitter 0 13ms store done n/a n/a 127.0.0.1 node-0 n/a n/a 0 0
100% 13 0 0 100% 9928 0 0 100.0%
This example data already has named fields and I believe all /_cat endpoints do as well. I am well-aware that I can use different output formats  and pass that data to an external tool for parsing, but that doesn't feel like the cleanest solution here.
If URI search is truly not enabled on these endpoints, does it make sense to add it?
As an admin on a few Elasticsearch clusters, knowing how to answer these questions (if not with uri search) will be a great help.
Further investigation leads me to believe that the .monitoring-es-* indices will be able to answer my questions. Is this the approach I should be taking? Does it provide the same dataset?