studio-agent-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STUDIO_ALLOW_SCRIPTS | No | Set to 1 to enable explicitly trusted native Python with the user's application and filesystem privileges. It is not a sandbox. Use 0 to retain only the predefined operations. | 0 |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| studio_statusA | Probe native hosts and list available action names without editing a document. |
| studio_plan_workflowB | Return role handoffs and acceptance requirements for one to three hosts, in order. |
| studio_plan_environmentB | Plan a detailed editable environment built in Blender and transferred to Unreal. The chat client performs the modeling through native actions. Defaults target high detail, complete occupied zones, PBR surfaces and multi-view visual review. This returns requirements, not a scene or evidence of completion. |
| studio_create_jobB | Create a durable single-host modeling job; use one job per host in an interop plan. |
| studio_execute_actionB | Execute one serialized native action and validate output evidence. Revision is required. Paths in parameters are relative to STUDIO_WORKSPACE. Scripts require server-side opt-in. Blender run_script with input_blend also requires expected_source_sha256 from the reviewed artifact. Return status describes this action, not completion of every project goal. |
| studio_inspect_jobC | Read durable state and verify event-chain/snapshot consistency. |
| studio_list_artifactsC | List all completed-action artifacts and recheck their current SHA-256 and size. |
| studio_recovery_reportA | Inspect durable recovery evidence without editing files or launching a host. Reports unresolved intents and preserved run directories. It does not detect whether a native process is idle, repair files, or authorize automatic replay. Inspect the actual host and artifacts before explicit reconciliation. |
| studio_reconcile_jobA | Record trusted operator inspection after interruption, allowing new actions. Do this only after inspecting the actual native host and output files and ensuring the previous process has stopped. This records a claim; it is not a rollback or an independent idle detector. Never infer host_is_idle from the bridge lock alone. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| studio_workflow | Plan native model creation and evidence review with explicit specialist roles. |
| studio_environment | Build and revise complete detailed Blender environments through chat, then Unreal. |
| studio_review | Review one job's measured artifacts against its design goal. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| roles | |
| capabilities |
TDQS
Scored across 9 tools
Each tool targets a distinct stage of the job lifecycle (create, inspect, execute, reconcile) with fairly precise descriptions. The main risk is overlap among the read-only tools: studio_inspect_job, studio_status, studio_recovery_report, and studio_list_artifacts all involve inspection, though the descriptions do delineate durable state vs. host probing vs. recovery evidence vs. artifacts.
All tools share a clear 'studio_' prefix and snake_case, and most follow a verb_noun pattern (create_job, inspect_job, plan_environment, execute_action). A few, notably studio_status and studio_recovery_report, use noun forms rather than verbs, which is a minor deviation.
Nine tools is well within a healthy range and each maps to a distinct workflow stage: planning, job creation, execution, inspection, and recovery. No tool appears redundant or frivolous for the stated bridge purpose.
The surface covers the core lifecycle: plan, create, inspect, execute, list artifacts, reconcile, and recovery reporting. The notable gap is no cancellation or deletion of a job and no explicit update/re-configure operation, which agents may need for cleanup.