IRSofka Workstation MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ue_worldB | Scene actors on the editor side: spawn / bulk_spawn / duplicate / set_transform / get_transform / attach / delete / get_all_actors / select_actors / set_lighting / set_physics / set_visibility / set_folder / set_tags / set_material / level_streaming. spawn resolves friendly class names to /Script/Engine.* and refuses to send one it cannot resolve; set_transform reads the transform back and reports what actually landed. |
| ue_blueprintC | Blueprint authoring: create / add_variable / add_function / add_call_function / connect_pins / set_pin_default / compile / get_summary. |
| ue_materialC | Materials and instances: create_material / create_instance / set_parameter / set_texture / set_static_switch / get_parameters. |
| ue_mediaC | Audio, Niagara and Sequencer: import_sound / bind_sound / play_sound / spawn_niagara / set_niagara_parameter / create_sequence. |
| ue_visionC | Viewport eyes: capture (active viewport as an image) and frame (move the camera onto an actor). |
| ue_pipelineC | Run ordered steps in one call with PARTIAL reporting: a step that fails does not erase the ones that already ran, and an editor that stops answering aborts the rest instead of dropping them silently. |
| ue_statusA | Bridge facts: endpoint, whether the editor answers, the class table this server resolves, and how many steps a pipeline may take. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Bridge protocol | the framing the editor's socket answers, read from the plugin source |
| Class table | which short class names this server resolves, and why |
TDQS
Scored across 7 tools
Each tool maps to a clearly distinct domain: world actors, blueprints, materials, media, viewport vision, pipeline orchestration, and bridge status. The only possible overlap is ue_pipeline invoking operations from other tools, but its ordered-multi-step purpose is explicitly different from direct domain calls.
All tools follow a consistent ue_<domain> naming pattern with lowercase snake_case-like names. The convention is predictable and readable across the entire set.
Seven tools is well within the ideal range and matches the server's domain-grouped design. Each tool represents a coherent editor subsystem rather than an arbitrary or redundant operation.
The surface covers many major editor areas, but there are notable lifecycle gaps such as blueprint component/event authoring, material deletion or graph editing, and sequencer keyframe editing. These gaps are workable in some cases but will likely cause agent dead ends for common Unreal workflows.