There are many different forms of input data for 3D Tiles tilesets. For example, point clouds, imagery data, general meshes (created from scans, e.g. for buildings or terrain), or CAD data. And in many cases, these input data sets already do contain metadata, in many different forms. (There’s that joke: “What is ‘metadata’?” - “It is a word with eight letters!” 
).
The point is that there can hardly be a general rule about which metadata should be represented in which form in the resulting tileset. This is why the 3D Metadata Specification that is used in 3D Tiles allows different representations of metadata, on different levels of granularity. This is illustrated in this image:
The latter might be a technical level of detail that is not relevant for end-users. In many cases, Cesium ion is already preserving metadata from input data, and making it available in a form that is suitable for the respective type of data. For example:
- Support for transporting metadata from LAS (point cloud) data into 3D Tiles, as described in Preserving More Metadata for Point Clouds Using 3D Tiles – Cesium
- Support for transporting metadata from IFC (CAD) data into 3D Tiles, as described in https://cesium.com/blog/2025/03/20/cesium-design-tiler-ifc-metadata/
- …
So when you ask about how to “prepare” a tileset for assigning metadata, then it may be necessary to talk about some of the details:
- What is the source data type? (Point clouds, CAD data…?)
- Does the source data already contain metadata?
- Which parts of the metadata should be preserved?
- Are there any use-case specific requirements for the granularity of the metadata?
- …
For certain complex, user-specific use cases, it may be necessary to assign metadata in a way that is not completely automated, and there again, many details depend on the type and granularity of the data. But even if certain steps may not be fully automated today, any feedback about actual real-world use cases can help us to prioritze the developments in this area.