Items and distribution

check_listed_items

[Experimental] Re-judge LISTED vehicles against TODAY's gates (executes the bundled helix vehicle recheck-listed). A listed item is never re-judged when a gate is added, so a car can be on sale on a visual-QA record that predates the gate that would fail it — the F40 was listed before the posture and hands-while-steering asserts existed, and sold with its driver lying back, hands off the wheel and fingers twitching. For each car it reads the passing record of its current version and reports CURRENT, STALE (names every current blocking gate the record never ran) or FAIL (names the gates it failed). With rerun: true it renders each car again NOW (preview_vehicle on the published car: every seat occupied, the full gauntlet inspection set and its sheets) and reports that verdict and the failing asserts. Run it before and after you update a listed car; with no itemIds it re-checks every listed vehicle (or one creator's). STALE or FAIL is ADVICE, never a block: it does not stop a listing or a sale. To improve such a car, run the helix-gauntlet loop, stage a new version of the SAME item and read the visual-check notes (advisory). Exit 0 = every car current (and passing today), 1 = a car has notes worth reading.

create_item_distribution

Runs the bundled CLI (helix item distribution create) and returns its output: creates one creator-authorized primary Claim/Buy route for a published item. This does not republish the definition or charge another publish fee. World routes require the owned world slug plus a stable key; Marketplace routes carry neither. LISTING IS SHIPPING, so look first: the helix-gauntlet loop on the published item is strongly advised (for a vehicle: preview_vehicle({ item }) with every inspection sheet looked at, and check_listed_items({ itemIds: [itemId] })), but it is advice, not a requirement. The visual check never gates a listing: for a vehicle whose visual-QA record is missing, stale or failed, the CLI prints advisory notes and lists it anyway. Only an unusable file or content safety refuses (the error says why).

delist_item

Runs the bundled CLI (helix item delist). Unlist a published item DEFINITION the creator owns (CH-1671). Existing owners keep what they already have; the item stops appearing on browse/marketplace and nobody new can acquire it through ANY of its distributions. This is not a delete: owned item definitions remain so current owners keep their content. Different from disable_item_distribution, which only turns off ONE acquisition route. Not currently reversible (no relist).

disable_item_distribution

Runs the bundled CLI (helix item distribution disable): disables an acquisition route without deleting its history or item definition.

get_asset

Read one HELIX Vault asset, including immutable artifact URL, MIME type, version, provenance, visibility, and world-usage receipts.

get_item_build

WHAT IS IN A LOOK (API identifier: build): its base, every add-on installed on it, which of them you already own, and what the parts cost together. Call it on any item whose buildKind is set — search_items marks those — before deciding to use a preset, because a Look is a RECIPE and not a bundle: it is never owned itself, and its parts are still owned and bought individually, from their own listings, so totalPriceLix is the SUM of the parts rather than a price the Look itself charges. Answers 404 for an ordinary item, which is the normal case and not an error worth reporting. A part whose Continuum Package Version is not pinned to a marketplace item yet comes back with item: null and is counted in unresolvedPartCount — that part is genuinely in the Look and genuinely unavailable, so never read the remaining parts as the whole Look. For the dressed character itself — model URLs and fit data, ready to render, not just prices — use get_look instead.

inspect_item_definition

[Experimental] RETURNS A COMMAND, NOT DATA. This tool hands you a helix … command string to RUN yourself — it executes nothing and returns no results. The answer is in that command’s output. Prepare the CLI command that resolves a PUBLISHED item definition and prints what an author tunes against — a weapon cadence, ammo, damage, spread and sounds; an emote its playback mode and pinned clip, plus the joiner clip and offset when it is a paired one. Read-only.

install_asset

Resolve one durable Vault id, download the exact immutable version, verify server SHA-256 and byte count, then write public/helix.assets.json provenance. Material installs default to the lean runtime KTX2 family; request source for editable PNG maps or all only when both families are genuinely needed. The CLI owns rendition selection and installation. For reproducible installs, supply version, checksumSha256, and sizeBytes together. Any mismatch fails before a receipt is written.

item_thumbnail

Request a fresh server render of an ALREADY-PUBLISHED item's catalog thumbnail (avatar, wearable, add-on, vehicle, ...) you own, and get back the preview URL — runs in-process, no CLI step. The catalog card is rendered by HELIX with the standard renderer from the item's ACTIVE Package Version, with one fixed camera and lighting preset per item type; creators CANNOT upload or override it (action=set is gone and is refused). Use this after a corrected Package Version, or when the card still shows an older mesh; pass dryRun first to see what would change without writing, and force to re-render when the server says it is already current. To correct a Package-backed mesh, seal a new Package Version and move the item onto it, then request the render here. A creator-owned item only (403 otherwise); an older backend answers 'does not support thumbnail refresh yet'. Not for worlds: use set_world_thumbnail.

list_asset_versions

List immutable versions of one Vault asset, including URL, MIME type, byte count, SHA-256, notes, and creation time.

list_item_distributions

Runs the bundled CLI (helix item distribution list --json) and returns every active or disabled primary distribution drawing from one item definition.

publish_owned_item

RETURNS A COMMAND, NOT DATA. This tool hands you a helix … command string to RUN yourself — it executes nothing and returns no results. The answer is in that command’s output. Move an existing creator-owned Universal Item onto one exact sealed Continuum Package Version using the approved Publications workflow. This does not create an Item, add an offer/distribution, or upload loose bytes. The Package must be public, sealed, current, and match the Item. A content-rating attestation is required; no backend receipt shape is defined by MCP.

scaffold_item_definition

[Experimental] RETURNS A COMMAND, NOT DATA. This tool hands you a helix … command string to RUN yourself — it executes nothing and returns no results. The answer is in that command’s output. Prepare the CLI command that authors a COMPLETE, valid interactive item definition — no hand-written descriptor JSON. Two item types, and the type decides which arguments apply. type:"weapon" (the default) builds it from a mesh plus a category (Rifle | Pistol | SMG | Shotgun | Sniper | LMG | Launcher | Grenade), which resolves the engine spread and reload tables, the grip preset and the shell class; with no sounds directory it copies category-default shot sounds next to the descriptor. The two explosive categories also carry the fire kind: a Launcher fires a projectile round, a Grenade is THROWN and is never rack-equipped — the blast itself (damage fanout, the fuse, the FX) stays world-authored, read_doc({name:"shooter-worlds"}) section 9. Mesh convention: grip point at the ORIGIN, +y up, +z out the barrel, meters. type:"emote" builds it from an animation clip GLB instead: the performance IS the item, so there is no mesh, no category and no gun config, and the clip has a hard duration ceiling — 10s as playback "oneshot", 60s as playback "loop". A PAIRED emote (one another player joins in on) adds a second clip, where that player stands, and an optional offerAtS — the pose the initiator holds while waiting, as seconds into their own clip. Either playback pairs. The scaffold prints the exact roles block to paste in, or pass joinerClip + joinerOffset + offerAt to the descriptor. An emote may also carry TRANSITIONS: introClipPath is the enter clip played into the body clip, outroClipPath the exit clip played out of it (a sit-down before a sit loop, a stand-up after it). Each caps at 5s, and on playback "oneshot" intro + clip + outro together cap at the same 10s — the player is locked for the whole chain. A PAIRED emote takes NEITHER: a joiner arrives on a held offer, so there is no shared instant to chain a transition into. Follow with validate_item_definition. This legacy descriptor format has no Item-first publishing route; use the approved sealed-Package publication flow for new content. For the consumption side (installWeaponItem before attach), read_doc({name:"shooter-worlds"}) section 8.

search_assets

SECOND ASSET RUNG: typed search over reusable HELIX Vault resources — call it before generating anything, and before looking at external/CC0 sources. THE INSTALLABLE TABLE: hits here are the ones install_asset takes (props, models, materials, animations); for sealed Continuum Packages — Scenes, vehicles, weapons, devices, Looks — search_vault is the different table. Finding is not using: install what fits and place it, or say why you passed. Executes the packaged HELIX CLI and returns a COMPACT row per hit (id, title, kind, short description, format, size, performance tier, key dimensions, reuse counts, artifact + thumbnail URLs) — enough to choose. Bulk per-item metadata and selectionExplanation are omitted; get the full record for ONE asset with get_asset, its versions and checksums with list_asset_versions, or pass detail:true for the raw payload (large — it truncates). Prefer origin="generated" for trusted pipeline provenance and engine="web" for browser worlds. Ranking signals are independent — lexical match, hard filters, measured performance, observed reuse — never one magic score. Character rows carry skeleton (and skeletonVerification where the publish gate measured it): the browser runtime plays humanoid rigs, so a verified humanoid skeleton is what makes a character web-playable.

search_items

THE MARKETPLACE SHELF, not the Vault stockroom — and the only way to find a LOOK. search_assets searches raw creator RESOURCES (the meshes, clips and materials a world is built out of); this searches published PRODUCTS: what a creator has already finished, priced and listed. Two different tables answering two different questions, so reach for this one whenever the question is "has somebody already made this?" rather than "what parts exist?". A LOOK (API identifier: build) is a published, dressed-character (or vehicle/weapon/device) preset — a base plus the exact add-ons installed on it, pinned as an immutable Continuum Build Package — and it exists precisely so you do not have to reassemble it: for a police world, prefer a finished police character over sourcing a base, finding a uniform and proving the fit yourself. A LOOK IS NEVER OWNED ITSELF: it is a free, always-available preset, and its parts are still acquired individually from their own listings — applying one never grants, buys, or moves anything you do not already own. A Look is NOT its own category (a character Look IS an avatar, a vehicle Look IS a vehicle), so builds defaults to include and a plain query for "police" returns finished Looks alongside the parts. Every row carries buildKind when it is a Look — that field is the ONLY thing distinguishing a preset from the base it was assembled from. Inspect one with get_item_build for its part list and prices, or get_look for the dressed character (base + add-ons with model URLs) ready to render.

search_vault

THE CONTINUUM VAULT CATALOG — a different table from search_assets (which holds the props install_asset installs), and the ONLY discovery tool that finds LOOKS and Scene Packages (packageType "scene": a ready-made place to pin as a world's scene instead of building one). search_assets hits the legacy raw-resource table, which has no Looks and never will; this hits /api/v1/vault/catalog, the table backing the website's Vault page, which lists every sealed, listed Continuum Package: Looks (pass packageType: "look"), characters, vehicles, weapons, devices, add-ons, materials. A LOOK (API identifier: build) is a free, never-owned dressed-character preset — its parts are still acquired individually from their own listings. Public: works signed out. Each hit that is a Look carries a compact build summary (its base and add-on slots); read the dressed character with model URLs and fit data via get_look, or the parts and prices via get_item_build.

track_asset

Read the backend-measured usage receipt for one durable Vault asset id: current/lifetime world usage, last use, and published worlds. Unobserved usage remains zero/null rather than a fabricated popularity score.

update_asset_metadata

RETURNS A COMMAND, NOT DATA. This tool hands you a helix … command string to RUN yourself — it executes nothing and returns no results. The answer is in that command’s output. Update creator-owned Vault annotations only. Immutable artifact bytes, kind, skeleton, compatibility, and version are never mutated. Byte changes must enter through a sealed Continuum Package; direct Vault byte-first version uploads are retired.

update_item_distribution

Runs the bundled CLI (helix item distribution update): reprices or changes schedule/caps on an existing distribution. Item, channel, world and stable key are immutable. Pass unlimited to clear a cap and none to clear a schedule boundary.

validate_item_definition

[Experimental] RETURNS A COMMAND, NOT DATA. This tool hands you a helix … command string to RUN yourself — it executes nothing and returns no results. The answer is in that command’s output. Prepare the CLI command that validates an item descriptor OFFLINE: the manifest authority validator, the vendored rules for the descriptor type, referenced-file existence, and the mesh precheck. A weapon is checked against the engine gun-config rules; an emote is checked against its own — the emote block and a resolvable clip, no gun config, and the MEASURED clip duration against its playback ceiling (10s oneshot, 60s loop). A PAIRED emote (an emote.roles.joiner block) is checked the same way on BOTH clips, plus the joiner offset bounds and the offer instant, which must land inside the measured initiator clip. Enter/exit TRANSITIONS (emote.intro / emote.outro) are measured too — 5s each, and on a "oneshot" intro + clip + outro together against the 10s ceiling — and are refused outright on a paired emote. Run it after any hand edit.

visual_qa_item

Runs the bundled CLI (helix item visual-qa) and returns its output and exit code: renders a published item's CURRENT package version headless in the real HELIX runtime (test-grounds world for vehicles AND whole avatars — the avatar is tried on as the player and walked —, the customiser for add-ons and wearables on every declared host/base, the item viewer for props, the item page for emotes, the Home walk-through for scenes), measures it (wheels at hubs, arch clearance, socket placement, on-body bounds, scale, NaN/invisible, textured; for avatars also materials resolved, no emissive wash-out, lit colour vs its own base colour, limb twist and skin tearing while walking), and with --submit records the backend's verdict — numeric asserts plus a vision critic — against that exact version, with a contact sheet. The visual check is ADVISORY: it records notes with fix hints and never gates a listing, a distribution, a version move or a publish (only a technical failure, an unusable file reported with its plain reason, or content safety blocks). Run it after every publish or new version, read the notes and the contact sheet, fix what you agree with, and re-run. Exit code 0 = pass (or warn: advisory notes only), 1 = fail (notes, never a gate), 2 = harness error (never a pass). To have the platform render it instead of this machine, use visual_qa_item_hosted.

visual_qa_item_hosted

Runs the bundled CLI (helix item visual-qa --hosted) and returns its output and exit code (create_avatar and publish_avatar_version already wait for this verdict for you): asks the PLATFORM to render and judge an item's current package version on its hosted GPU runner — no Chrome, no GPU, no QA login on your machine. It queues one hosted run per (item, package version, manifest), waits, and exits 0 = passed (an avatar may be verdict: warn: advisory warnings[], terminal, nothing else to wait for), 1 = failed (advisory notes: reasons and blockers[] printed; never a gate), 2 = error / timed out, printing the contact sheet URL. Use this instead of visual_qa_item when this machine has no suitable browser (CI, a sandbox, a remote agent), or after a deferred Marketplace publish, which can queue a hosted run for you (the response carries hostedRun: { jobId, status }; follow it with visual_qa_item_status). The hosted notes are advisory, the same as a local --submit run: nothing waits on them. A freshly sealed model can lag the CDN; the runner waits for it (<=10 min) and a lag never uses an attempt. Retry (requeue a fresh job) after a failed/errored/exhausted run only once the item is fixed or the failure was infrastructure (retry:true).

visual_qa_item_status

Runs the bundled CLI (helix item visual-qa --status, read-only) and returns an item's hosted visual-QA state: the latest hosted job for its CURRENT package version (queued / rendering / passed / failed / error, attempts, reasons, error), the verdict (pass, warn, fail or error: an avatar passed job with verdict warn is TERMINAL: advisory warnings[], nothing else to wait for) and its warnings[] / blockers[], the contact sheet URL, and whether the current version has a passing run (advisory; nothing waits on it). Needs no login and changes nothing. Exit code 0 = passed (or warn) or still in flight/none, 1 = failed, 2 = error. Use it to follow a hostedRun from a deferred publish.