Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
HUNYUAN_WORKBENCH_ROOTNoPath to the data directory. Overrides the default location (e.g. %LOCALAPPDATA%\hunyuan-workbench on Windows). Must be set consistently for all calls using the same task set.

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
workbench_capabilitiesA

Observed feature catalog, inputs, tested status and current limitations. Excludes world generation.

workbench_prepareB

Validate/copy/deduplicate 3..8 views including front. Does not submit or consume quota.

workbench_prepare_featureC

Validate a feature specification and preserve local inputs. See capabilities and README for schemas.

workbench_listA

Read durable local jobs; no browser calls.

workbench_getA

Read one job, its input hashes and state history; no browser calls.

workbench_browser_startA

Start/reconnect the persistent local browser. Uses its existing official web login.

workbench_browser_runA

Upload and configure the full job in one local execution. submit=True generates once and starts local monitoring with automatic download; consumes web quota.

workbench_submitA

Submit an already prepared READY form exactly once. Use only with user authorization for this job; may consume web quota.

workbench_statusC

Read local state or enqueue a fresh check of the exactly bound web asset.

workbench_watchA

Configure persistent local task monitoring. Checks happen in the worker without repeated model calls. Stopping monitoring does not cancel generation.

workbench_watchesA

Read monitor results, errors, next check times and attention flags from disk.

workbench_downloadB

Select the matching completed asset, download via official UI, validate and archive. Never generates again.

workbench_assetsA

List currently loaded visible asset cards and thumbnail identities on this job page. Does not enumerate unloaded pages.

workbench_recoverC

Explicitly rebind an interrupted task only after reviewing its matching completed asset. Thumbnail must identify the one selected card. Never generates.

workbench_browser_inspectA

Read the visible job page or default page for diagnosing a changed UI.

workbench_browser_resultA

Retrieve one local request result. Read watches for generation progress; do not repeatedly inspect the page.

workbench_ingestB

Validate/archive a manually downloaded artifact for a confirmed successful job.

workbench_blender_scriptC

Create a separate background Blender import script with metres, normalized height and grounded origin.

workbench_doctorB

Inspect local runtime, worker heartbeat and persisted monitoring state.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3/5.0

Scored across 19 tools

Disambiguation2/5

Multiple read/state tools (list, get, status, watch, watches, browser_result, doctor) have overlapping 'read local state or monitoring results' purposes, and browser_run vs submit can both lead to generation. The descriptions do help distinguish them, but an agent still faces several near-boundary choices.

Naming Consistency3/5

All tools share the workbench_ prefix and snake_case, which gives a readable family feel. However, the naming convention is mixed: some are verb_noun like browser_start and prepare_feature, while others are bare nouns or verbs like list, get, watches, assets, capabilities, and doctor.

Tool Count3/5

At 19 tools, the server is in the borderline-heavy range. Most tools map to a real workflow stage, but several status/watch/result variants could likely be consolidated.

Completeness4/5

The server covers the core generate-monitor-download-archive lifecycle, including recovery, manual ingest, diagnostics, and basic Blender integration. Minor gaps exist around cancellation and cleanup/delete operations, but the intended workflow has no obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues