Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
WEAPONLAB_BLENDERNoBlender, for Motion Lab. Found on the PATH or in the usual install folders otherwise.
WEAPONLAB_PROJECTNoThe project folder with `weaponlab.json`. The current folder by default.The current folder

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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
project_infoB

The project in use: its folder, data, specs and work folders, the probe command, Blender.

contract_checkC

Checks a file against its contract: a probe's job, rows or parts dump, or a digitizer file (sources, blueprint, partsmap).

spec_listC

Every weapon spec: marks, actions, marks still proposed.

spec_readC

One weapon's spec, with the default limits filled in.

spec_validateD

Every problem with a spec, as sentences (empty: whole).

spec_writeB

Saves a whole spec and returns what changed.

gate_casesD

The cases (each a known bug as a metric, a weapon, an action and a pass rule).

gate_metricsB

Every metric: provider, unit, which way is better, tolerance.

gate_weaponsD

The project's weapons.

gate_add_caseC

Adds or replaces a case.

gate_runC

Measures the weapons with the providers (probe, rig, or the project's own) and stores the run.

gate_verdictC

Pass only if the target cases pass, nothing else got worse past its tolerance and the checks are trusted.

gate_set_baselineC

A run's rows become the baseline (merged over the old).

gate_proposeC

A staged change measured and judged; the proposal waits for a person's approval.

gate_approveB

Marks a passed proposal approved. Only on a person's word.

gate_proposalsD

Every proposal: passed, approved.

gate_evalsC

Each provider's eval: faults caught, good cases passed, trusted.

probe_statusC

The processes that must not run with the probe, running now.

probe_planD

The job's weapons the probe would get.

probe_runD

One probe run: rows, and screenshots and parts dumps at the moments.

rig_piecesD

A parts dump's pieces (triangles, centre, bounds, extents) and twins (a piece drawn twice).

rig_factsD

The weapon spec's facts (order, side, below, in) on a dump.

rig_alignD

A magazine's line into its well over a reload's moments: worst offset and tilt while in the well.

rig_part_lineD

A sliding part's path against its axis: line_cm and seat_cm.

rig_fistD

A melee hilt against the fist's grip channel, and the turn and move that lay it in (try them with probe_run's tune; a palm-down fist can hold the hilt right and still point the blade sideways: look at the screenshot).

motion_roll_profileC

The hand's roll about its forearm through a clip (0 thumb up; past 80 degrees breaks the forearm's range).

motion_rollC

One clip's hand turned about its forearm, the twist bones sharing it.

motion_roll_setC

A set of clips rolled, each from its own start, saved under new names (_).

motion_trackD

A sliding part's track rebuilt on its axis from its seat.

motion_renderD

Dev views of parts dumps (not the game's view).

gunkit_actionsB

The kinds of gun action Gun Kit knows (AR gas, AK handle, bolt, lever, pump, pistol slide, open bolt, revolver, belt fed, launchers, bow, crossbow, flamethrower, fictional energy guns): each one's guns, parts and clips.

gunkit_actionB

One action in full: its parts, marks, the beats of its gun clips and the hand events of its hand clips, with the reason or source of each, and the manuals to read or find.

gunkit_inspectC

What a model holds as Blender shows it after import (objects, vertex groups, bounds, the longest axis, a units guess): the starting point of its parts map.

gunkit_draftD

A first parts map for a model of the user's own and the list of every guess in it to confirm (forward, units, the bolt face, each part, each mark). Write the confirmed map to a file for gunkit_rig.

gunkit_from_modellabC

A Model Lab build's parts map (its moving parts, travel, hinges and hand marks), ready for gunkit_rig.

gunkit_proxyD

An action's proxy gun (simple shapes with its real moving parts) built and rigged: the whole chain runs on it before a real model exists. A test model: label every picture of it.

gunkit_rigC

A gun rigged for its action from its parts map: one bone a moving part, the gun facts checked against the action.

gunkit_buildC

Every clip of one gun: the hand clips on the shared arms (Pose Lab: the hold searched for both hands and the view, each clip's clearance, anatomy and grip checks, the expected sights), then the gun's own clips with the carried parts' tracks. Minutes per gun.

gunkit_verifyD

The gun's own clips read back from Blender against the timeline's sums: the worst gap a clip, cm.

gunkit_exportC

The gun's files staged for a game: its FBX with its clips, the hand clips, an import plan, a draft data file and a trial copy pointing at staging. Registers the build for the Gate's gunkit provider.

gunkit_casesC

The Gate cases every gun of an action gets (its facts, each clip's read-back, each hand clip's checks and sights); add writes them into the Gate.

blueprint_source_addC

Step 1: registers a file (PDF or picture) as one of a gun's sources, with its license. Opens it as data only.

blueprint_scanC

Every page of a source sorted into text, table, figure, mixed or blank, with the figure pages' captions.

blueprint_pageC

Pages as pictures to read: one page at dpi, or several side by side (a contact sheet) to find the figures.

blueprint_textC

A page's text, or the lines matching a pattern across the sources (where a part or a number is named).

blueprint_specsC

Step 2: candidates for each data table quantity (overall length, barrel length, weights...): the line, the numbers near it. Check a candidate on the page picture before adding it.

blueprint_fact_addC

Records a fact (kept in cm, kg, deg or count) with its page and quote.

blueprint_figure_addC

Step 3: cuts a figure from a page and stands it upright.

blueprint_gridD

The figure with a labelled pixel grid (and, once framed, its bore line, origin and cm grid) to read points off.

blueprint_calibrateC

A figure's scale: two points a known length apart (a printed scale bar's ticks, or a fact), or a kept outline's length along the bore against a length fact.

blueprint_frameD

How a figure lies in gun space: the bore line (from the rear toward the muzzle) and the bolt face.

blueprint_alignD

A figure's scale and frame matched to a framed figure on a part both show (a trigger guard's opening).

blueprint_traceC

An outline from a figure, kept for the plan: the whole silhouette, a closed area round a seed, a rough outline snapped onto the ink, or a patch in a halftone. Look at the picture it writes.

blueprint_measureC

Readings off a figure by the tools, not by eye: a distance, the ink's span along a line, a scale bar's ticks, the count and pitch of faint marks.

blueprint_newD

Step 4: starts the gun's blueprint for its action family.

blueprint_partB

Sets one part of the blueprint. Every number needs its source; the check fails a part without one.

blueprint_holeC

A cut in a part: a kept trace's outline or a circle across x (limited to x when given), or a bore along y.

blueprint_markD

A mark in gun space (cm) with its source: a hand's place (with the way its surface faces) or a point a check needs.

blueprint_viewsC

The detail pass: a part shaped by three views (its side outline, front sections, a top outline), each with its source.

blueprint_featureC

The detail pass: a surface feature on a part (grooves and screws in the mesh, patterns as the finish's texture).

blueprint_parts_listC

The detail pass: the source's parts list, each part visible or hidden; the check holds every visible one to a blueprint part (by number, or by name when the source gives none).

blueprint_numbersD

The source's part numbers a blueprint part stands for.

blueprint_readD

The gun's blueprint or sources document as it stands.

blueprint_checkC

Step 5: the blueprint against its contract, its reference outline (overlap, edge gaps), its length and weight facts; and overlay pictures on every framed figure. Look at the overlays.

blueprint_buildC

Step 6 in Blender: the model (one object a part) and its parts map for Gun Kit; with render, labelled pictures of it from both sides and three quarters.

blueprint_showcaseC

A showcase of a built gun that has been through Gun Kit (minutes in Blender): a title card, the source beside the copy, a turn round it, its clips (fire slowed, the reloads, the checks); as a GIF and an MP4, every frame labelled as a Blueprint Lab model view.

blueprint_to_gunkitC

Step 7: the built model through Gun Kit (several minutes in Blender): rig, hand clips, gun clips, read-back.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.3/5.0

Scored across 67 tools

Disambiguation4/5

The toolset is divided into clear functional prefixes (blueprint_, gunkit_, gate_, rig_, motion_, spec_, probe_), and within most groups each tool targets a distinct step or resource. A few near-pairs (gunkit_actions vs gunkit_action, gate_cases vs gate_evals, gunkit_rig vs blueprint_to_gunkit) could be misselected, but descriptions generally disambiguate them.

Naming Consistency4/5

Nearly all tools follow a predictable snake_case prefix_noun pattern (blueprint_scan, gunkit_rig, gate_run, motion_roll), grouped logically by pipeline stage. A couple of outliers (project_info, contract_check) break the prefix scheme, but overall naming is highly consistent.

Tool Count2/5

67 tools is a heavy surface for a single server, with 25 blueprint_* tools alone, which risks overwhelming an agent despite the pipeline's complexity. The scope is real but the count is well beyond a comfortably navigable set.

Completeness4/5

The surface covers a full weapon-development lifecycle: source ingestion, blueprint authoring, rigging, animation, gating/baselining, and export. Coverage appears broad with few obvious dead ends, though minor gaps in areas like proposal rejection/rework may exist.