What a Control Rig actually needs: the control hierarchy, gizmo sizes, two bone IK and a pole vector that points the right way. Then how I automate the repetitive half, and the two things that went wrong doing it.
Loading…
Drop the plugin into your project, point your MCP client at it, and let your AI actually build inside the editor.
Rigging in Unreal is mostly not hard. It is fiddly. You build the same control hierarchy you built last time, size every gizmo by dragging it until it stops looking wrong, wire two bone IK, and then scrub the timeline hoping the knee bends the right way.
A Control Rig in Unreal Engine 5 needs five things, in this order: an asset created from your skeletal mesh, a hierarchy of controls parented to the bones they drive, gizmo shapes sized so an animator can actually see and click them, two bone IK on the limbs with a pole vector aiming each elbow and knee, and a check that the thing evaluates rather than merely existing.
Four of those five are describable, which means they are automatable. Below is each step, what it actually involves, and the command that does it, including the two places it went wrong, because those are the interesting parts.
One command creates the asset and imports the skeleton's bone hierarchy:
Create the rig from a skeletal mesh:
cfa create_control_rig_from_skeleton --asset-path "/Game/Rigs/CR_QueenMarika" --skeleton-path "/Game/Characters/SKM_QueenMarika"At this point you have bones and nothing to grab. An animator needs controls, and controls need to be in the right places with the right shapes.
This is the part that is genuinely tedious by hand. Every control is a create, a parent, a rename, and a transform, repeated forty times. It goes in one call:
Build the whole hierarchy atomically:
cfa build_rig_hierarchy --asset-path "/Game/Rigs/CR_QueenMarika" --json '{"elements":[{"type":"control","name":"root_ctrl","shape":"Circle_Thick"},{"type":"control","name":"spine_01_ctrl","parent":"root_ctrl","bone":"spine_01"},{"type":"control","name":"spine_02_ctrl","parent":"spine_01_ctrl","bone":"spine_02"}]}'Every rigger knows this one. A freshly created control is a unit circle sitting inside the character's ribcage, invisible and unclickable, and you fix it by dragging a scale value until it looks about right. Forty times.
It can be measured instead. The command reads the actual skinned vertices for each bone and sizes the shape to fit them:
See what it would do without touching anything:
cfa fit_rig_control_shapes --asset-path "/Game/Rigs/CR_QueenMarika" --dry-run trueThen apply it:
cfa fit_rig_control_shapes --asset-path "/Game/Rigs/CR_QueenMarika" --margin 1.25The dry run habit is worth keeping. It prints the size it computed per control, so an obviously wrong number shows up before it is applied to forty gizmos at once.
One control came out enormous. A 143 centimetre circle around a bone that should have had a five centimetre one.
The cause turned out to be a socket. The fitting logic walks a bone's children to work out how far the shape needs to reach, and a socket parented at the bone's origin counts as a child sitting at distance zero in a way that skewed the measurement. Not a bug in the character, and not something you would ever guess from looking at the result.
The fix was to zero the socket's local translation rather than delete it, because deleting a socket breaks whatever was attached to it. The point is not the specific bug. It is that a dry run surfaced a single absurd number in a list of forty reasonable ones, which is exactly the kind of thing you do not notice when you are dragging sliders.
Pole vector placement is the other job that is pure arithmetic dressed up as art. The knee has to point the way the foot points, and the maths for that is knowable from the bones:
Place the pole vector from the limb's own geometry:
cfa place_rig_pole_vector --asset-path "/Game/Rigs/CR_QueenMarika" --control "pole_knee_l_ctrl" --root-bone "thigh_l" --mid-bone "calf_l" --end-bone "foot_l" --facing-bone-a "foot_l" --facing-bone-b "ball_l"Passing the two facing bones is what stops the knee pointing sideways. Without them the direction is a guess, and a guess is wrong about half the time.
The rig reported healthy and the controls did nothing. Every status was green, the hierarchy was correct, the shapes were right, and moving a control moved nothing.
This is the trap in rigging automation generally: a status that says success only tells you the call did not error. It does not tell you the rig evaluates. The only thing that proves a rig is alive is running it and watching what moved.
Check the controls are wired at all:
cfa validate_rig_controls --asset-path "/Game/Rigs/CR_QueenMarika"Then actually run it over an animation:
cfa simulate_rig --asset-path "/Game/Rigs/CR_QueenMarika" --anim-sequence "/Game/Anims/A_Walk" --frames 90The simulation is headless. It reports which bones moved and by how much, whether limbs crossed through each other, whether anything went below the floor, and whether any transform came back NaN. That is a verdict, not a status.
For a hero character you are art-directing, probably not end to end. You will want your hands on the controls that carry performance.
For the other forty characters, the ones that need a competent rig and no more, this is the difference between a day and twenty minutes. It is also repeatable, which matters more than it sounds: the same commands run against the next skeleton produce the same rig, instead of whatever you happened to do differently on a Friday.
Worth saying plainly: Control Rig physics is Beta in 5.8 and Experimental before that. Epic's own flags say so. If you go down the jiggle and secondary motion route, budget iteration time and do not trust a green status.
The full Control Rig walkthrough, with every validation gate spelled out, is in the docs, and every rigging command is listed in the Control Rig reference.
Control Rig is one of 28 categories, and the rest work the same way. 900+ commands across 28 categories, on UE 5.6, 5.7 and 5.8. Drive it from Claude Code, Cursor, VS Code, or any MCP client.
Three day free trial. No card, nothing locked off, and it runs on your real project.
Want a corner of the editor reachable that is not covered yet? Say so in Discord. Most of what exists came from exactly that.