An app like that is probably not too hard to develop, but it would be time consuming.
In one scenario, you'd have to effectively create the equivalent to the in-game [props gump, but using WinForms or WPF.
Reflection would play a huge part in populating data tables, but the most work would be involved in writing the logic to handle the varying data types of each property.
There is a reason that [Props accessible properties need to be marked with a [CommandProperty] attribute, and that is for access intention.
I'm not talking about staff access level, I'm talking about the ability to access (get or set) an individual property.
Properties not marked with a [CommandProperty] attribute were obviously never intended to be edited on the fly by staff and are likely only meant to be updated programatically, therefore it would be a good idea to use a similar role with this application.
It can allow the user to access any properties marked with a [CommandProperty] and ignore those that are not.
This kind of application would need to be launched by the running shard, so that the shards memory is more easily accessible to the application and there would be pre-existing support and references for cross-code development.
In another scenario, you could have an application that's capable of reading/writing the world save files without the shard running.
This application would simply use the ServUO.exe and Scripts.CS.dll as references, so that it would support cross-code development.
In order to load the world save files, the application could simply invoke and execute the code responsible (that already exists) for loading the world saves.
The problem with this approach is that all the entities - mobiles and items - will have their Deserialize method called...
Because RunUO/ServUO don't have standards that restrict Deserialization to only reading data, there can and will be unexpected results - some items or mobiles might have special logic in their Deserialize methods that does things like delete them, or starts a timer, or anything else except simply reading data and assigning it to a properties.
There is also the caveat that loading the data this way will also just fail because corrupt data is corrupt data and that's that, no matter the interpretation of the data.
That leaves the previously mentioned database-driven (SQL) save file as the only other viable option - you can probably just discount the second option I mentioned completely because of the caveats. For achieving the goals set out in this post, the database model would be the ideal candidate - but it just doesn't exist in a stable, production state... yet.
