An obvious choice for a tool for designing metamodels for MMX M2 level (MMX/M2) is UML class diagram. Class diagram is a mixture of elements concerned with both data structures and behaviour, and we are only interested in data structures aspect. The important elements that we need to consider while mapping an UML class diagram to MMX/M2 are: classes, interfaces, objects, attributes, annotations, associations, generalizations, enumerations and data types. Here's how those elements are mapped to the constructs of MMX Metamodel:

classes An UML class is implemented as an instance of MD_OBJECT_TYPE. A mandatory name column contains the name of the class and there's an indicator column to denote whether the class is an abstract or a concrete one.
interfaces An interface is implemented in exactly the same way as an abstract class.
objects An UML object is an instance of a class. Objects are implemented as instances of MD_OBJECT that get their object types supplied by MD_OBJECT_TYPE. The relationships between MD_OBJECT and MD_OBJECT_TYPE are essential for consistency of MMX model and are enforced by the facilities of referential integrity provided by the underlying database.
attributes An UML class attribute is implemented as an instance of MD_PROPERTY_TYPE. Each row in this table is related to the owner class of the attribute, and to the domain class of the attribute (a data type or an enumeration). In case a default value is provided it is stored in the default value column.
packages Package element is currently not mapped to MMX metadata model as it provides no additional benefits in this context. A metamodel is always assumed to belong to a single package with a single namespace.
annotations Comments and notes are stored as a text column of a class diagram element instance that it belongs to.
associations An UML association between two classes is implemented as an instance of MD_RELATION_TYPE. Each row in this table has two relations with MD_OBJECT_TYPE, one for each end of the association, and a name made up of both role names (all mandatory columns). An association type column indicates whether the row denotes an association, an aggregation or a composition, with null value denoting an association. Note that relationships in MMX metamodel are directional by design. 
aggregations An aggregation relationship is implemented exactly as an association, with the association type of aggregation ('A').
compositions A composition relationship is implemented exactly as an association, with the association type of composition ('C').
multiplicity Multiplicity of an association is stored in multiplicity type column of MD_RELATION_TYPE and takes a value from the predefined set of multiplicity types. The following notation is used:
0..1 (optional, zero or one) 'Z'
1 (one, or an exact number n) '1' ('n')
0..* or * (zero, one or more) '*'
1..* (at least one)  'P'
generalization Generalization has a very special role in MMX metadata model architecture as the mechanism for maintaining class hierarchies. Inheritance is implemented as parent-child relationship of MD_OBJECT_TYPE realizing superclass and subclass relations between classes. Note that MD_PROPERTY_TYPE and MD_RELATION_TYPE also have this relationship and can therefore constitute hierarchies of their own. Multiple inheritance is not permitted due to the single-parent nature of the parent-child relationship.  
enumerations Enumerations are implemented as instances of MD_OBJECT_TYPE inherited from an abstract domain class. Enumeration literals are stored as instances of MD_OBJECT related to one particular MD_OBJECT_TYPE.
data types Like enumerations, UML data types are instances of MD_OBJECT_TYPE inherited from an abstract data type class. Unlike enumerations, data types do not have an implicit set of possible values.
constraints UML constraints are technically just informal annotations to the model that have to be taken care of during system implementation. MMX Metamodel does not support constraints in any formal way so they are left for an application to handle. 


Not all UML class diagram elements and features (eg. those designed for code generation) are relevant in the scope of metamodeling and are therefore not considered here. As an example, visibility property of class attributes is of no concern in metamodel context. Similarily, not all MMX/M2 features are required for mapping UML class diagrams.