Watch a real example of the current workflow. How is a level assembled, checked, saved, and tested? Which steps require a developer? Which errors appear repeatedly? These observations help define a tool that solves a practical production problem.
Build around a small complete task
The first version might place objects, set a few properties, validate required elements, and launch a test. It does not need every imaginable feature. A tool with a clear save format and useful checks can be more valuable than a flexible interface whose outputs frequently break the game.
Include the people who will use it in early testing. They should be able to complete the task without the tool's author explaining hidden rules. Error messages need to identify the problem and a way to correct it.
Think about versioning and updates. If the game's data format changes, existing levels may need migration. If the tool is handed to another team, documentation and dependencies matter. Keep the ownership and maintenance expectations explicit. A useful production tool earns its place by making content work more dependable, with the complete create-test-revise cycle demonstrated rather than assumed from a successful save button.