# Loom by SubverseLab (mcpb · loom-0.4.4.mcpb)

Reads your own Ableton projects and writes MIDI, chains and markers into a running Live set.

- Trust score: 49/100 (low)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-21

## Components

- mcpb · `loom-0.4.4.mcpb`: 49/100 (this document), [markdown](https://verifymcp.io/servers/senolsahan037-oss-loom/https-github-com-senolsahan037-oss-loom-releases-download-v0-4-4-loom-0-4-4-mcpb.md), [page](https://verifymcp.io/servers/senolsahan037-oss-loom/https-github-com-senolsahan037-oss-loom-releases-download-v0-4-4-loom-0-4-4-mcpb)

## Channel facts

- Registry: `mcpb`
- Package: `https://github.com/senolsahan037-oss/loom/releases/download/v0.4.4/loom-0.4.4.mcpb`
- Version: `0.4.4`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-21.

- **Supply Chain Security**: 25/100
  - Malware scan not yet available for this package.
  - Known CVEs were checked across the 29 of 29 dependencies we could resolve, so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - 1 of 29 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 35/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - License check failed: the license (SEE LICENSE IN LICENSE) isn't a recognized OSI-approved license.
  - Actively maintained (last published 9 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 80/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 9030 tokens (~192/item across 47 items; 45 tools + 2 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 30/100
  - Stability observed for 9 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 99/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 98% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 45 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 47 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

- Download bundle: `https://github.com/senolsahan037-oss/loom/releases/download/v0.4.4/loom-0.4.4.mcpb`

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-20 (score 49, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-19 (score 48, +3)

- [functional improvement] Stability: unverified → 0.23

### 2026-09-12 (score 45)

First indexed and scored.

## MCP tools (45)

### `part_suggest` (~270 tokens)

Write a chord progression or bass line FOR A SPECIFIC PROJECT. Reads the project's own key, scale and tempo first, walks a chord sequence through transitions measured from 909 annotated songs, and returns notes already in that project's key and beats -- so the part belongs to the session rather than having to be bent to fit it. This is the thing a prompt-driven generator cannot do: it does not know your key or your tempo. Returns what it read from the project and what it counted, so every choice is traceable. A layer with no measured evidence is refused, not guessed.

Input parameters:

- `als_path` (string): The .als to read the musical context from. Omit to use the running Live session.
- `bars` (integer): Length in bars.
- `beats_per_bar` (number): Beats in a bar (Live beats = quarter notes): 4 for 4/4, 3 for 3/4 and 6/8.
- `chords_per_bar` (integer): Harmonic rhythm. 1 is one chord a bar; 2 is half-bar changes.
- `layer` (string, required): Which part to write.
- `octave` (integer): Octave for the chord voicing.
- `seed` (integer): Same seed and same project give the same part.

### `genre_evidence` (~250 tokens)

Musical evidence measured from open corpora of real performances, served one layer at a time. 'drum' returns where each drum part falls on the bar for a style, counted from 1,150 human drummer takes. 'bass' returns how the bass sits against the chord and how far it moves. 'chord' returns degree transitions and melodic intervals. 'arrangement' returns song-level shape -- chord counts, loop lengths, modes -- which is what ArrangementGPS needs to build a project rather than write notes. Layers are kept apart on purpose: a bass line judged by a kick pattern answers the drum question, not the bass one. A style that was never measured returns nothing instead of an approximation.

Input parameters:

- `layer` (string, required): Which layer's evidence to return.
- `song_maps` (integer): For the arrangement layer: how many per-song maps to include (0 for the summary only).
- `style` (string): For the drum layer: rock, funk, jazz, hiphop, latin, reggae, soul, country, punk, gospel, afrobeat, afrocuban, neworleans, pop. Trap/rap map to hiphop, r&b to soul.

### `midi_generate` (~608 tokens)

Generate evidenced MIDI variations using Sensei's locked dataset and variation runtime for a verified target role/preset.

Input parameters:

- `auto_write_to_live` (boolean): If true, writes the generated notes into a session clip through the Loom extension -- only when the part is writable_to_live (drum: pad_notes given; bass/chord: instrument_verified); otherwise the an…
- `bars` (integer): Number of bars to generate (e.g. 2, 4, 8).
- `beats_per_bar` (number): Beats in a bar (Live beats = quarter notes): 4 for 4/4, 3 for 3/4 and 6/8.
- `density` (number): How busy the part should be, 0.0 sparse to 1.0 busy -- an intro against a final hook. Selects a pattern from the corpus that already has that note count for the role; notes are never dropped from a d…
- `explicit_profile_id` (string): Explicit instrument profile ID (e.g. 'ableton.bass.808.v1', 'ableton.bass.synth.v1', 'ableton.chord.piano.v1', 'ableton.chord.pad.v1').
- `genre` (string): Native Ableton genre (e.g. 'Trap', 'Hip Hop', 'House', 'Techno', 'Ambient').
- `genre_style` (string): Rank candidates by how well they match drum patterns measured from real performances of this style (rock, funk, jazz, hiphop, latin, reggae, soul, country, punk, gospel, afrobeat, afrocuban, neworlea…
- `instrument_verified` (boolean): For bass/chord: the caller has verified an instrument device on the target track in Live.
- `pad_notes` (array): For role drum: the pad notes read from the Drum Rack in Live (live_command op drum_pads). Without them the part is an offline suggestion on the General MIDI map and is not writable to Live.
- `preset_path` (string): Optional path or name of the Suite native instrument preset.
- `role` (string): Musical role of the target track.
- `seed` (integer): Random seed for deterministic generation.
- `target_mode` (string): Scale mode.
- `target_root` (string): Key root note (e.g. 'C', 'D#', 'F', 'A').
- `track` (string): For auto_write_to_live: the MIDI track to write into.
- `variation_amount` (number): Variation intensity (0.0 to 1.0).

### `midi_write_arrangement` (~401 tokens)

Write MIDI notes into the ARRANGEMENT of a running Live session -- a named track, a bar position, a length -- through the Loom extension. Every note, length and target is validated in Live before anything changes. A clip in the range that Loom did not write is never touched (the write is refused); Loom's own clip there is replaced only with on_conflict=replace_owned, so rebuilding a section is safe and a user's clip is safe. Reports the note count Live holds and whether the notes match note-for-note; NOT_CONSUMED means the request was withdrawn unapplied, INDETERMINATE that Live picked it up and never answered.

Input parameters:

- `beats_per_bar` (number): Beats in a bar. Omit to take it from the running session's own time signature (or the .als if als_path is given); 4/4 is assumed only when neither is available, and the response says which.
- `idempotency_key` (string): Optional key for a retry: the extension answers a repeated key with the stored outcome instead of writing again.
- `length_beats` (number): Clip length in beats.
- `name` (string): Clip name, e.g. the section: Intro, Verse 1, Hook.
- `notes` (array, required): Notes relative to the clip start, in beats.
- `on_conflict` (string): When the range already holds a clip: refuse (default), or replace it if Loom wrote it. A clip Loom did not write is never touched either way.
- `start_bar` (integer): 1-based bar the clip starts on, converted with the session's own time signature.
- `start_beat` (number): Alternative to start_bar: absolute start in beats.
- `track` (string): Track name in the session. Omit to use the selected track.
- `wait_seconds` (number): How long to wait for Live to consume the request.

### `midi_write_to_live` (~287 tokens)

Write MIDI notes into a session clip in Ableton Live through the Loom extension bridge (op write_clip on the common protocol) and wait for Live to answer. Reports WRITTEN_TO_LIVE, REJECTED_BY_LIVE, NOT_CONSUMED (withdrawn, nothing applied) or INDETERMINATE (Live picked it up, no answer). An occupied slot is never overwritten unless the clip is Loom's own and on_conflict=replace_owned.

Input parameters:

- `length_beats` (number): Total length of the clip in beats (default 16.0 = 4 bars in 4/4).
- `name` (string, required): Name for the generated clip in Ableton Live.
- `notes` (array, required): List of note objects with pitch, start, duration, velocity.
- `on_conflict` (string): What to do when the slot holds a clip: refuse (default), or replace it if Loom wrote it.
- `prompt` (string): Optional descriptive text or prompt string for audit trail.
- `slot` (integer): Session slot index. Omitted: the first empty slot.
- `track` (string): MIDI track name, exactly as Live shows it. Omitted: the first MIDI track.
- `wait_seconds` (number): How long to wait for Live to actually consume the request before reporting. 0 queues blindly without verifying anything.

### `project_inspect` (~60 tokens)

Inspect an Ableton Live Set (.als) file in detail: tempo, key, scale, Camelot code, track breakdown, mute states, and active devices.

Input parameters:

- `als_path` (string, required): Absolute or relative path to the .als project file.

### `project_detect_genre` (~46 tokens)

Analyze track names, arrangement density, and instrument presence in an .als file to predict multi-label genre tags.

Input parameters:

- `als_path` (string, required): Path to the .als file.

### `project_analyze_mixer` (~82 tokens)

Full gain-staging and mixer analysis of an .als -- real fader values, Utility gains, routing kind, send routes, and master-chain limiter/clipper/compressor detection, with a markdown report. XML only; peak/RMS/LUFS targets need rendered audio.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.

### `project_build` (~803 tokens)

THE single trigger: build a whole project into the running Live session from one prompt, through the Loom extension. Runs plan_create (its own run directory), validates the plan, checks the extension's published capabilities, then in order: tempo -> tracks (created or adopted, a native instrument inserted when the SDK can, Drum Rack pads read back as evidence) -> a part per section and writable track (drum, bass, chord; the section's energy as density, the plan's genre as genre_style, in the project's key and tempo) -> a locator per section -> a read-back of the state. Song key is reported UNSUPPORTED_BY_SDK, never faked. A track whose instrument or pads could not be verified gets blocked writes, not silent ones; when the bridge stops answering the remaining writes are aborted. The answer's status is completed / partial / blocked / failed / indeterminate. Dry run by default: it reports exactly what it would write and touches Live only with dry_run=false.

Input parameters:

- `allow_lossy_kit` (boolean): IGNORED by project_build (reported as such): a plan kit is never reconstructed from samples here; a kit that cannot be loaded is PRESET_LOAD_REQUIRED. The explicit, separate op is live_command build_…
- `beats_per_bar` (number): Beats in a bar. Omit to read the running session's time signature; 4/4 is assumed only as a last resort and reported as such.
- `device_map` (object): Per-track native device to insert instead of the plan's preset name, e.g. {'Main Bass': 'Operator', 'Keys': 'Electric'}. The SDK cannot load presets; without a mapping a preset-named track is created…
- `dry_run` (boolean): true: report the write list, change nothing in Live. false: write.
- `kit` (string): Explicit user override for the drum tracks' preset references. Omit to resolve each track's own planned kit. Selection provenance and original plan references are reported. Reconstruction requires al…
- `plan_path` (string): Use an existing session plan instead of running plan_create -- for a rebuild, or to test the write list without the Node chain.
- `preset_load` (string): How a plan track gets its REAL preset in the open set. 'os' (default): the track is created empty and the preset file (.adg/.adv the family names, found on this machine) is handed to Live through mac…
- `prompt` (string): Musical brief, e.g. 'dark rolling tech house, 126 bpm, in F minor'. Omit when plan_path is given.
- `seed` (integer): Base seed; each track and section derives its own from it.
- `set_manifest` (string): The manifest project_file_build wrote next to the set that is now open in Live. A drum track whose kit is in the manifest and whose pads Live reports exactly is verified as that preset (nothing rebui…
- `tracks` (array): Build only these plan tracks (by ableton_name). An explicit simplification: the answer lists what was dropped and why. Omit to build every plan track.
- `wait_seconds` (number): Per request, how long to wait for Live to consume it.

### `plan_create` (~201 tokens)

Build a project from scratch: run the real pipeline from a text prompt (blueprint -> build plan -> session plan -> package -> action list) and write a build directory ArrangementGPSBuilder picks up in Live. Tempo, key, mode, genre and instrument choice are derived from the prompt. Each section carries a 0-100 energy and the plan carries a genre; when the Live-side writer fills the sections it hands Sensei that energy as density (an intro is written from a pattern that is already sparse, a final hook from one already busy) and the genre as genre_style (candidates ranked against drum patterns measured from real performances). Every part is written in the project's own key and tempo.

Input parameters:

- `prompt` (string, required): Free-text musical brief, e.g. 'dark rolling tech house, 126 bpm, hypnotic bassline'. State a tempo as '<n> bpm' and a key as 'in F minor' to have them honoured.

### `library_search` (~117 tokens)

Search Sensei's preset identity catalog (role- and genre-tagged, so a hit is something Sensei can actually generate for) with an optional filesystem fallback for name-only lookups.

Input parameters:

- `genre` (string): Restrict to presets carrying this native Ableton genre tag, e.g. 'House', 'Hip Hop'.
- `limit` (integer): Maximum results.
- `query` (string): Substring of the preset name (lowercase match).
- `role` (string): Restrict to presets Sensei resolves to this role.

### `render_plan` (~81 tokens)

Build a per-track stem export manifest from a real .als, deciding from the project itself which tracks can be rendered and why the others cannot (MIDI needs a freeze, groups and returns are excluded).

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.
- `project_title` (string): Optional title; defaults to the .als filename.

### `live_bridge_status` (~98 tokens)

The single connection diagnosis: which Loom extension bridge the MCP talks to (and why), its freshness, session and published capabilities, the operations the SDK cannot do, and what is waiting in the queue. Says whether this MCP may send mutations to the running extension (protocol verdict: OK / UPGRADE_REQUIRED / PROTOCOL_MISMATCH / STALE_STATE / NO_STATE) and the state of its replay journal. There is no fallback endpoint.

### `gap_record` (~94 tokens)

Log an identified missing control, untested path, or desired Live API feature into docs/MISSING_CONTROLS_LOG.md.

Input parameters:

- `category` (string, required)
- `description` (string, required): Detailed description of what operation was attempted or needed.
- `observed_behavior` (string, required): What occurred or why current tools were insufficient.
- `required_implementation` (string, required): Recommended remote script, M4L, OSC, or bridge implementation.

### `project_file_build` (~336 tokens)

Build the plan's tracks WITH THEIR REAL PRESETS as a Live set file. The Extensions SDK cannot load a preset into an open set (insertDevice: built-in device, default preset only), so the set is written on disk from Live's own template: one MIDI track per plan track, the preset ArrangementGPS chose (a Drum Rack .adg with its DrumCells, macros and choke groups; an Instrument Rack; an .adv) converted into set XML by Presetor and refused whenever a produced node does not match, tag for tag and attribute for attribute, what Live itself writes; the plan's tempo. No representative device is ever inserted: a track whose preset is not on this machine is not created and is listed under unresolved. Writes a manifest next to the set; open the set in Live, then project_build(plan_path=..., set_manifest=...) writes MIDI and locators into those tracks with the kit verified against the manifest. Measured 2026-09-07 on Live 12.4.15b1: the first such set loaded with 0 repairs.

Input parameters:

- `name` (string): Set name; default: the plan's project name.
- `out_dir` (string): Where the project folder is created. Default: ~/Desktop/Loom Builds.
- `plan_path` (string): An existing session plan (the same one project_build will use afterwards).
- `prompt` (string): Musical brief for plan_create. Omit when plan_path is given.
- `tracks` (array): Plan tracks to build; default: every track Sensei can write (drum, bass, chord).

### `plan_verify` (~51 tokens)

Check the current session plan against Sensei's catalog -- every track with a Sensei role must name an instrument that resolves to exactly that role. Catches the Live-side instrument_role_unresolved failure without opening Live.

### `project_inspect_arrangement` (~54 tokens)

Read an .als arrangement -- tempo, time signature, locators, and the section boundaries inferred from where clips start and stop across tracks.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.

### `drumbuss_build` (~93 tokens)

Build the native EQ Eight -> Glue -> Utility drum buss chain in an .als. Dry run by default; applying writes a timestamped backup first and verifies the result after saving.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.
- `apply` (boolean): Write the .als. Leave false to preview only.
- `source` (string): Source track name to build the buss from.

### `projects_arrangement_shapes` (~91 tokens)

Scan a library of .als projects and report how the user actually arranges -- section lengths, section counts, song lengths and tempos, inferred from clip boundaries. Evidence for arrangement templates instead of guesswork.

Input parameters:

- `limit` (integer): Maximum number of .als files to read.
- `roots` (array): Directories to scan. Defaults to ~/Desktop, ~/Documents and ~/Music/Ableton.

### `project_analyze_clips` (~91 tokens)

Check arrangement clips for gain/fade/automation alignment problems -- clip gain outside the allowed range, missing fades, and clip vs track volume automation conflicts.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.
- `limit_db` (number): Maximum absolute clip gain in dB before it is flagged.
- `threshold_db` (number): Clip gain below this is treated as unity.

### `automation_read` (~57 tokens)

List every automation envelope in an .als, resolving each PointeeId to the owning device and parameter. Read-only -- nothing in this stack can write automation yet.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.

### `drumbuss_read` (~48 tokens)

Read the drum buss device parameters out of an .als and report whether they match the conservative preset. Read-only.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.

### `chain_evidence` (~96 tokens)

What device chains the user actually builds, counted from their own projects. With no role, returns the whole measured summary; with a role, the evidence-backed chain and each device's presence rate. A role with too little data returns no recommendation instead of a guess.

Input parameters:

- `role` (string): e.g. kick, snare, hat, bass, sub, keys, pad, lead, perc, sample, bus, fx.

### `live_project` (~190 tokens)

Open, inspect or close an Ableton Live project. Live's own scripting cannot open or close a set, so this drives it from outside and then reads Live's own log to say whether the set really loaded -- whether it was corrupt, how many clips Live had to repair, and which audio files it could not open. Opening another set while Live is running can raise Live's unsaved-changes dialog, which only the person at the keyboard can answer; nothing is discarded automatically.

Input parameters:

- `allow_switch` (boolean): Open a set even though Live is already running. A set switch also kills an installed Extension (Extension Host crashes inside the SDK): the Loom bridge is gone until Live is restarted.
- `als_path` (string): Project to open, for op=open.
- `op` (string, required): What to do.
- `wait_seconds` (number): How long to give Live before reading the verdict.

### `chain_plan` (~62 tokens)

For every track in an .als, report its role, its current device chain, the evidence-backed chain for that role, and which track in the same project could donate it. Read-only.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.

### `chain_apply` (~141 tokens)

Copy a device chain from one track to another inside the same .als. Device XML is never synthesised -- it is cloned from a real device with fresh Pointee ids. Refuses to overwrite a track that already has a chain. Dry run by default; applying writes a timestamped backup first and re-reads the file to verify.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.
- `apply` (boolean): Write the .als. Leave false to preview only.
- `donor_track` (string, required): Track whose chain is copied.
- `target_track` (string, required): Track that should receive the chain. Must currently be empty.

### `palette_read` (~79 tokens)

The user's measured sound palette -- which sample sources and instrument devices actually recur, per role, ranked by how many separate projects each appears in. Bounces, freezes and reverb impulse responses are excluded.

Input parameters:

- `role` (string): e.g. kick, snare, hat, bass, keys, pad, fx. Omit for the full summary.

### `project_sound_sources` (~40 tokens)

List one project's sound sources -- instrument devices per track and the samples they load.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.

### `automation_write` (~214 tokens)

Write an automation envelope onto a track's mixer parameter in an .als. The envelope targets the parameter's own AutomationTarget id -- nothing is invented -- and values are checked against that parameter's real range. Dry run by default; applying writes a timestamped backup, saves atomically, then reloads the file and compares every point.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.
- `apply` (boolean): Write the .als. Leave false to validate only.
- `parameter` (string): Mixer parameter to automate. Use pointee_id instead for device parameters.
- `pointee_id` (string): Automation target id of a device parameter, from automation_list_targets.
- `points` (array, required): Breakpoints in time order.
- `replace` (boolean): Overwrite an envelope that already exists on this parameter.
- `track` (string, required): Track name exactly as Live shows it.
- `unit` (string): 'db' is accepted for volume only and is converted to Live's linear gain.

### `render_verify` (~109 tokens)

Measure exported stems against the project's own render manifest -- which expected file is missing, which is silent, which has the wrong channel count. Rendering itself needs Live's audio engine and cannot be done from here; this checks the result afterwards.

Input parameters:

- `als_path` (string, required): Absolute path to the .als the stems were rendered from.
- `project_title` (string): Optional title; defaults to the .als filename.
- `renders_dir` (string, required): Directory holding the exported .wav/.aif stems.

### `live_state` (~184 tokens)

Read Ableton Live's current state -- which set is open (name, path, saved or not; from Live's log and window title, the SDK has no such field), tempo, transport position, selected track, every track's mixer values and devices, and the song's locators. Published by the Loom extension running inside Live (the SDK exposes no transport or time signature; those are null). Always reports how old the snapshot is and whether it is fresh; if Live is not running it says so instead of returning stale data as if it were live.

Input parameters:

- `include_devices` (boolean): Include each track's device list.
- `max_age_seconds` (number): Above this age the snapshot is reported as not fresh.
- `refresh` (boolean): Ask Live for a fresh dump before reading.
- `wait_seconds` (number): How long to wait for the refresh.

### `live_command` (~1074 tokens)

Make a live change inside a running Ableton Live through the Loom extension: set tempo, mixer volume/pan/mute/solo, a device parameter, a locator, a new MIDI track (with a native instrument device when the SDK can insert it), an audio file imported into the project as a clip, a pre-effects render of an audio track range, or read a Drum Rack's pad notes (drum_pads); delete_track / delete_locator remove what an earlier build left behind (a track only when it holds no clip and its devices are named exactly). The extension writes the real before/after values back, so the answer is what Live actually did. Operations the Extensions SDK has no API for -- transport, set_key, preset loading, the capture_* recording steps -- are answered UNSUPPORTED_BY_SDK before anything is sent.

Input parameters:

- `action` (string): Transport action.
- `allow_lossy_kit` (boolean): For build_drum_kit with kit: explicitly accept sample reconstruction instead of preserving the preset. Missing samples are refused even with consent.
- `beat` (number): Locator position in beats.
- `bpm` (number): Tempo for set_tempo.
- `device` (string): Device name on that track.
- `duration_beats` (number): For import_audio_clip in the arrangement: clip length in beats (default: the sample's natural length).
- `end_beat` (number): For render_pre_fx: range end in beats.
- `expected_devices` (array): For delete_track: exactly the device names the track holds, in order. A track with devices is refused (track_has_devices) unless they are named; a track holding any session or arrangement clip is ref…
- `include_devices` (boolean): For get_state.
- `index` (integer): For delete_track: the track's index as live_state reports it; refused (index_mismatch) if the named track is elsewhere.
- `instrument_family` (string): For create_midi_track: a native device name (e.g. 'Drum Rack', 'Operator'); the SDK inserts it with its default preset. A browser preset name is not loadable and the outcome says not_loadable_in_exte…
- `kit` (string): For build_drum_kit instead of pads: a Drum Rack preset -- a .adg path or a kit name from Sensei's catalogue (e.g. 'Boom Bap Kit'). Its pads, notes and sample files are read from the preset's own XML…
- `mode` (string): For set_key: Live scale name, e.g. 'Minor'.
- `mute` (boolean): Mute state.
- `name` (string): Locator name, or the exact name of the MIDI track to create (create_midi_track adopts an existing MIDI track of that name rather than duplicating it). For delete_track: the exact track name (must mat…
- `op` (string, required): Operation to run inside Live. build_drum_kit assembles a kit on the track's Drum Rack from sample files (one chain + Simpler per pad; presets still cannot be loaded). transport, set_key and capture_*…
- `pads` (array): For build_drum_kit: [{note: 36, sample: '/abs/path/kick.wav', name: 'Kick'}, ...]. Existing pads are never replaced; the pad notes are read back from the device afterwards.
- `pan` (number): Mixer pan, -1 to 1.
- `parameter` (string): Parameter name on that device.
- `path` (string): For import_audio_clip: the audio file to import (Live copies it into the project).
- `position` (number): Playhead position in beats.
- `root` (string): For set_key: root note, e.g. 'F' or 'A#'.
- `slot` (integer): For import_audio_clip: session clip slot index; omitted = first empty slot; omitted together with start_beat = arrangement.
- `solo` (boolean): Solo state.
- `source` (string): For journal_import: the bridge root of an earlier Loom extension id to carry the replay journal from. Omit to import every earlier id found on this machine.
- `start_beat` (number): For import_audio_clip: arrangement position in beats (instead of a slot). For render_pre_fx: range start.
- `track` (string): Track name, exactly as Live shows it. Must match exactly one track.
- `value` (number): New value for set_device_parameter.
- `volume` (number): Mixer volume, in Live's own parameter range.
- `wait_seconds` (number): How long to wait for Live to process it. 0 queues without verifying.
- `warped` (boolean): For import_audio_clip: warp the clip (default true).

### `automation_list_targets` (~145 tokens)

List every parameter on a track whose automation can be written -- mixer and device alike -- with its automation target id and declared range. A parameter that does not declare a range is left out rather than written with guessed bounds. Filter before raising the limit: a single EQ Eight carries 85 parameters.

Input parameters:

- `als_path` (string, required): Absolute path to the .als file.
- `contains` (string): Case-insensitive substring of the parameter tag, e.g. 'gain', 'freq'.
- `limit` (integer): Maximum parameters returned.
- `scope` (string): Restrict to mixer or device parameters.
- `track` (string, required): Track name exactly as Live shows it.

### `mix_measure` (~166 tokens)

Direct signal measurement of one audio file (a stem, a bounce, a master): duration, sample rate, channels, sample peak dBFS, RMS dBFS, crest factor, ITU-R BS.1770 integrated loudness through pyloudnorm, and per-channel peak/RMS/DC offset. Silence and too-short files come back with null levels and a status, never a made-up floor. No true-peak guesses, no custom loudness range. The SubverseLab Mix Check engine, running locally.

Input parameters:

- `max_duration_seconds` (number): Refuse files longer than this instead of measuring them (default 360).
- `path` (string, required): Audio file to measure (wav/aiff/flac/mp3...). A rendered stem from render_plan is the usual input.

### `mix_analyze` (~351 tokens)

Full Mix Check of one audio file: the measurements of mix_measure plus one-third-octave spectrum, tonal map with key candidate, noise floor, section summaries, mono fold-down compatibility, and evidence-backed findings. Optionally compared against a reference file or one of the stored Genre Profiles (measured from released masters: electronic, hiphop, jazz, metal, pop, rock); use_closest_profile ranks the track by technical proximity, which is not a genre classification and is labelled as such. Findings only appear when a measurement is actually outside the comparison range; limitations are listed with every result.

Input parameters:

- `analysis_stage` (string): What the file is. Master-only metrics (loudness, peak, crest) are compared only for a master.
- `detail` (boolean): Return every per-band table (31 one-third-octave bands for spectrum, mono fold-down and comparison deltas) instead of the compact form. The full answer exceeds the response limit and is then written…
- `genre` (string): Optional stored Genre Profile id to compare against (see mix_profiles).
- `include_waveform` (boolean): Include the 1200-bin waveform envelope in the answer (large). Default false.
- `max_duration_seconds` (number): Refuse files longer than this (default 360).
- `path` (string, required): The mix or master to analyse.
- `reference_path` (string): Optional reference file to compare against.
- `reference_stage` (string): Required when reference_path is given: what the reference is.
- `use_closest_profile` (boolean): With no genre and no reference: compare against the technically nearest stored profile and say so.

### `mix_profiles` (~39 tokens)

List the stored Genre Profiles mix_analyze can compare against: id, name, how many released masters each was measured from, and the measurement contract version.

### `crate_fetch` (~151 tokens)

Bring a source into the crate: a YouTube URL (yt-dlp + ffmpeg) or a local audio/video file, optionally trimmed, decoded to a 44.1 kHz stereo WAV in the crate's work directory. Returns the WAV path and the source metadata (title, video id, duration, trim). The SubverseLab Sampler's fetch stage.

Input parameters:

- `end` (string): Trim end.
- `source` (string, required): YouTube URL or a local file path.
- `start` (string): Trim start, e.g. '1:12' or '72'.
- `workdir` (string): Where to keep the decoded WAV (default: the crate work directory under Sessions).

### `crate_read` (~115 tokens)

Measure the audio itself, not its file name: level, noise floor, silence share, stereo width, tempo (from loop length + autocorrelation octave choice, 82% measured accuracy vs 31% for beat tracking) with its chop-range fold, onset rate, key with confidence, brightness and harmonic ratio. Says why when it cannot answer (one_shot, no_plausible_bar_count, ambiguous key, ableton_compressed). The SubverseLab sample-reader.

Input parameters:

- `path` (string, required): Audio file to read.

### `crate_spots` (~118 tokens)

Find chop candidates inside a longer recording: the top N windows ranked by harmonic content, onset density and level, each with a bar count, a score and the reason, plus the beat grid the ranking used. With a YouTube video id, the watch URLs that loop each spot. The sample-reader's spots stage.

Input parameters:

- `path` (string, required): Audio file to scan.
- `top` (integer): How many candidates (default 6).
- `video_id` (string): YouTube video id, to return loop URLs for each spot.

### `crate_chop` (~417 tokens)

Slice a recording into a sample pack the way the Sampler CLI does: modes transient, bars, fixed, silence, leftover or all; WAV slices per mode with fades, optional normalisation, a manifest that records how the slices were really produced (a given --bpm writes that grid, not librosa's estimate). Returns the pack directory, per-mode slice counts and the analysis.

Input parameters:

- `bars` (integer): Bars per slice in bars mode (default 2).
- `beats_per_bar` (integer): Default 4.
- `bit_depth` (integer): Default 24.
- `bpm` (number): Known tempo; overrides the estimate and writes that grid.
- `fade_ms` (number): Fade at slice edges in ms (default 5).
- `grid_offset` (string): Where the bar grid starts, as a timestamp, with bpm.
- `keep_source` (boolean): Copy the decoded source into the pack as _source.wav (default true).
- `max_len` (number): Longest slice in seconds.
- `max_slices` (integer): Per-mode cap (default 200).
- `min_len` (number): Shortest slice in seconds (default 0.08).
- `modes` (array): Chop modes (default ['transient']).
- `name` (string): Pack folder name (default: from the source title).
- `normalize_dbfs` (number): Peak-normalise every slice to this dBFS (omit for none).
- `out_dir` (string): Pack root (default: Sessions/SamplePacks under Loom).
- `path` (string, required): Decoded WAV (from crate_fetch) or any local audio file.
- `seconds` (number): Slice length in fixed mode (default 2.0).
- `source_meta` (object): Metadata from crate_fetch, recorded in the manifest.
- `tail` (number): Extra seconds after each transient slice.
- `top_db` (number): Silence threshold below peak for silence/leftover modes (default 30).

### `crate_agent` (~270 tokens)

THE crate trigger: from one source (YouTube URL or file) to a measured sample pack in one call. Fetches, reads the audio (tempo, key, quality), finds the chop spots, picks the chop mode from the evidence -- bars on the reader's own grid when the tempo is measured and inside the chop range, transients otherwise -- slices, and writes a pack whose manifest carries the reading, the spots and the reason for every choice. Nothing is guessed: a tempo the reader could not measure is reported as such and the pack falls back to transients. Dry run by default reports the plan without writing.

Input parameters:

- `bpm` (number): Known tempo, wins over the reading.
- `dry_run` (boolean): true: fetch, read and plan only; false: also slice and write the pack.
- `end` (string): Trim end.
- `modes` (array): Force these chop modes instead of choosing from the reading.
- `name` (string): Pack folder name.
- `out_dir` (string): Pack root (default: Sessions/SamplePacks under Loom).
- `source` (string, required): YouTube URL or local file.
- `start` (string): Trim start.
- `top_spots` (integer): How many chop spots to rank (default 6).

### `crate_to_live` (~194 tokens)

Put a crate slice (or any audio file) into the running Live set as an audio clip: Live imports the file into the project folder (its own managed copy) and creates the clip in a session slot or at an arrangement position on the named audio track. The answer carries the imported path Live chose and the clip it made.

Input parameters:

- `duration_beats` (number): Arrangement clip length in beats.
- `name` (string): Clip name.
- `path` (string, required): Audio file, e.g. a slice from a crate pack.
- `slot` (integer): Session slot index; omitted = first empty slot.
- `start_beat` (number): Arrangement position in beats instead of a slot.
- `track` (string, required): Audio track name, exactly as Live shows it.
- `wait_seconds` (number): How long to wait for Live.
- `warped` (boolean): Warp the clip (default true).

### `mix_from_live` (~147 tokens)

Measure what a track in the running Live set actually sounds like before its effects: the extension bridge renders the audio track's arrangement range pre-fx into its temp directory, then Mix Check measures the file (mix_measure) or analyses it (mix_analyze). One call from Live to numbers.

Input parameters:

- `analysis` (string): measure = direct signal values; analyze = full Mix Check (compact).
- `analysis_stage` (string)
- `end_beat` (number, required): Range end in beats.
- `start_beat` (number, required): Range start in beats.
- `track` (string, required): Audio track name.
- `wait_seconds` (number): How long to wait for the render.

### `mix_capture` (~294 tokens)

Measure the mix from Live's own playback, no render, with a Core Audio process tap on the Live process (method 'tap': macOS 14.2+, needs the System Audio Recording permission for the app running Loom; captures silence until granted -- experimental, the permission target is unverified). Then Mix Check measures or analyses the capture. method 'resample' (Live recording itself) and follow_transport need record mode and transport state, which the Extensions SDK does not expose: both answer UNSUPPORTED_BY_SDK.

Input parameters:

- `analysis` (string): measure = direct signal values; analyze = full Mix Check (compact).
- `analysis_stage` (string)
- `follow_transport` (boolean): Unsupported by the SDK (no transport state); true answers UNSUPPORTED_BY_SDK.
- `genre` (string): Optional stored Genre Profile id to compare against.
- `keep` (boolean): Keep the WAV (default true; the path is returned).
- `max_seconds` (number): Cap for follow_transport captures (default 60).
- `method` (string): tap = Core Audio process tap (default); resample is unsupported by the SDK and answers so.
- `position` (number): resample: arrangement position in beats to start playing from (default: where the playhead is).
- `seconds` (number): How long to capture (default 8).
- `use_closest_profile` (boolean)

### `setup_scan` (~87 tokens)

First-run setup: build Loom's catalogues from the stock Ableton library on THIS machine, read out of Live's own file index. Loom ships code and fixtures but never measurements, so each user generates their own. Reports state by default and writes nothing until asked.

Input parameters:

- `check_only` (boolean): Report which catalogues exist and whether Ableton's index is readable, without writing anything.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/senolsahan037-oss-loom/https-github-com-senolsahan037-oss-loom-releases-download-v0-4-4-loom-0-4-4-mcpb#diagnostics

## Score history

- 2026-09-21: 49
- 2026-09-20: 49
- 2026-09-19: 48
- 2026-09-18: 45
- 2026-09-17: 45
- 2026-09-16: 45
- 2026-09-15: 45
- 2026-09-14: 45
- 2026-09-13: 45
- 2026-09-12: 45

## Common questions

### What is the Loom by SubverseLab MCP server?

Loom by SubverseLab is an MCP server listed in the public MCP registry as io.github.senolsahan037-oss/loom. Reads your own Ableton projects and writes MIDI, chains and markers into a running Live set. This page covers its MCPB bundle (https://github.com/senolsahan037-oss/loom/releases/download/v0.4.4/loom-0.4.4.mcpb).

### Is the Loom by SubverseLab MCP server safe to use?

Loom by SubverseLab scores 49 out of 100 on VerifyMCP. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Loom by SubverseLab MCP server expose?

Loom by SubverseLab exposes 45 tools: part_suggest, genre_evidence, midi_generate, midi_write_arrangement, midi_write_to_live, and 40 more. Their descriptions and schemas cost roughly 8,902 tokens of context every time the server is loaded.

## Links

- Repository: https://github.com/senolsahan037-oss/loom
- Website: https://subverselab.com/loom
- Changelog RSS feed: https://verifymcp.io/servers/senolsahan037-oss-loom/https-github-com-senolsahan037-oss-loom-releases-download-v0-4-4-loom-0-4-4-mcpb.xml
- Changelog JSON feed: https://verifymcp.io/servers/senolsahan037-oss-loom/https-github-com-senolsahan037-oss-loom-releases-download-v0-4-4-loom-0-4-4-mcpb.json
- HTML version of this page: https://verifymcp.io/servers/senolsahan037-oss-loom/https-github-com-senolsahan037-oss-loom-releases-download-v0-4-4-loom-0-4-4-mcpb