Unreal-MCP-Ghost

Overview Schema Source Related Servers Discussions Admin

add_skeleton_socket

Add or replace a socket on a skeletal mesh's skeleton, defaulting to GunBarrel on the ik_hand_gun bone. Specify bone, transform, and scale; optionally save the skeleton.

Instructions

Add or replace a socket on the USkeleton used by a skeletal mesh (e.g. GunBarrel).

Infantry uses the GunBarrel socket name with GetSocketTransform on the mesh. Sockets are stored on the skeleton asset; Python mesh.add_socket is unreliable in UE5.6.

Defaults parent the socket to ik_hand_gun (Mannequin weapon IK bone) with a 22 cm offset along local +X (typical muzzle direction). Override relative_rotation as [pitch, yaw, roll] in degrees if traces fire along the wrong axis.

Args: skeletal_mesh_path: Content path to the USkeletalMesh (e.g. /Game/.../SithSoldier). socket_name: Socket name (default GunBarrel). bone_name: Parent bone (default ik_hand_gun; use hand_r if your rig has no IK gun bone). relative_location: Optional [x, y, z] in cm relative to the bone. relative_rotation: Optional [pitch, yaw, roll] in degrees. relative_scale: Optional [x, y, z] scale (default 1,1,1). save: If True, persist the skeleton package via low-level SavePackage.

KB: see knowledge_base/01_BLUEPRINT_FUNDAMENTALS.md#overview Example: add_skeleton_socket(skeletal_mesh_path="/Game/MCP_Test/Example")

Input Schema

TableJSON Schema

Name	Required	Default
`save`	No
`bone_name`	No	ik_hand_gun
`socket_name`	No	GunBarrel
`relative_scale`	No
`relative_location`	No
`relative_rotation`	No
`skeletal_mesh_path`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 20, 2026

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden and does so well: it states the mutating add/replace behavior, that sockets live on the skeleton asset, that save=True persists via low-level SavePackage, and the exact default parent/offset/rotation semantics. It even explains why this tool exists rather than relying on Python calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: purpose, rationale, behavioral defaults, parameter semantics, KB pointer, and a runnable example. The most important action and escaping notes are front-loaded before the argument list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no annotations, it is complete: all parameters have meanings and defaults, persistence behavior is defined, troubleshooting guidance is included, and a minimal example plus KB reference are provided. The existing output schema covers the return side, so no return-value prose is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the Args section fully compensates by documenting all 7 parameters, including units (cm, degrees), coordinate order, defaults, and the safe alternative value for bone_name. This is far more than the bare JSON schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair: add or replace a socket on the USkeleton backing a skeletal mesh, then anchors it in a concrete example (GunBarrel). This unambiguous combination distinguishes it from the many generalist sibling tools for actor/component properties.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete selection context: this is the socket operation used by Infantry's GetSocketTransform, and it explicitly warns that the Python mesh.add_socket alternative is unreliable in UE5.6. It also provides conditional guidance (use hand_r if no IK gun bone, override relative_rotation if traces fire on the wrong axis).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server