Weapon Lab
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WEAPONLAB_BLENDER | No | Blender, for Motion Lab. Found on the PATH or in the usual install folders otherwise. | |
| WEAPONLAB_PROJECT | No | The 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 67 tools
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.
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.
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.
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.