Yes I'm thinking about a slightly more general use-case because it would make a lot of people happy that have been requesting this in one way or another over the years.
At minimum I think you should consider that there can be two capture screens with their own status so ideally we want to get information about both and control both. With that in mind and the similar requests for control from other applications, I think it should be as high as possible in the hierarchy so it has the option to control everything and return the most information.
The top level has ways to get information about the screen supervisor and individual screens rather easily. If you would consider getting back a formatted string and extracting the information from it instead of directly getting a data structure it would be super general and most useful for every other use-case. The capture screen can be in several states: empty, connected, grabbing, recording.
So I think there should be an internal API to grab the global status from the top and then one or more entry points to expose this information to interested callers based on communication tech. The advantage of using an HTTPListener is that it would be super easy to test queries for other interested applications. Example applications: controlling via a Stream Deck, interfacing with record keeping software for competitions, advanced multi-cameras record/playback setups.