FaceLink
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FACELINK_INSTANCE_DIR | Yes | The directory where FaceLink stores instance data, used by the MCP server to connect to the Blender bridge and persistent state. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_blender_instancesA | List Blender windows that currently have the FaceLink bridge running. |
| facelink_healthB | Check connectivity and capabilities for one FaceLink Blender instance. |
| scan_sceneB | Read stable IDs, bounds, nav data, armature bones and Action channel inventories. |
| validate_retarget_profileA | Validate a rename-only or sampled pose-bake profile without changing Blender. |
| analyze_retarget_profileC | Measure hierarchy, rest-axis and proportion safety for a reviewed bone map. |
| suggest_retarget_profile_mapB | Suggest exact/normalized/alias bone matches; output always requires human review. |
| validate_shot_specC | Validate a typed shot without changing Blender. |
| preview_shotB | Compile a shot, including deterministic navmesh paths, without applying it. |
| stage_scene_patchA | Stage a patch in Blender for visible human review without changing the scene. |
| get_staged_patchA | Read the patch and artist-facing summary currently waiting for approval. |
| apply_staged_patchC | Apply the patch that a human has reviewed in Blender. |
| discard_staged_patchA | Discard the staged patch without changing Blender. |
| apply_scene_patchB | Power-user escape hatch: apply a white-listed patch without Blender review staging. |
| undo_last_applyC | Ask Blender to undo the most recent edit. |
| list_revision_historyA | List persistent FaceLink audit entries and current-session rollback availability. |
| rollback_to_revisionB | Undo the selected revision and every newer FaceLink revision in this session. |
| get_blender_jobA | Get the status of a previously submitted Blender job. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
The tools are largely separated by lifecycle stage and resource type, such as validate, preview, stage, apply, and rollback. A couple of pairs, like validate_retarget_profile vs analyze_retarget_profile and apply_staged_patch vs apply_scene_patch, are close enough to require careful reading, but the descriptions do distinguish them.
Most tools follow a clean action_object snake_case pattern like list_, get_, validate_, stage_, apply_, and discard_. facelink_health breaks the pattern as a noun phrase, and rollback_to_revision uses a preposition instead of a direct object, but these are minor deviations.
17 tools is slightly above the typical 3-15 range, but the server covers several distinct workflow areas: instance health, retargeting, shots, staged patches, and revisions. The count is reasonable for the scope, though it could be tightened.
The set covers the core safety-oriented lifecycle: scan, validate, preview, stage, review, apply, and rollback. Obvious minor gaps exist, such as no Blender job submission/cancellation and no explicit apply/save for retarget profiles, but agents can work around them via scene patches and external job submission.