Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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
configA

The paths on this machine the server needs (FL, loopMIDI, FL's Hardware folder, preset libraries), stored in kuruitsugizaki.json. Call it first in a new install, and whenever another tool answers that a key is not set. No arguments: every key with its value or the path detected for it, and whether that path exists. key alone: that key. key and value: set it. Never guess a path or search the disk for one: ask the user where it is, then set it.

fl_installA

Set up the live link to FL. Needed once per install, and again after this folder moves. Close FL first. It does two things: 1) writes FL's controller script into FL's Settings\Hardware folder (config key fl_hardware), with this folder's bridge path in it, replacing an older copy; 2) unless a MIDI input in FL already has the script, makes a loopMIDI port named kuruitsugizaki and assigns the script to it in FL's MIDI settings. Both live in the registry, which FL rewrites when it closes; if FL was open, the answer's midi entry says so and what to do by hand. Returns {ok, installed, bridge, changed, midi, next}. Then start FL and call fl_probe to see the script answer. Windows with FL Studio only.

fl_probeA

Check the live link to FL: returns FL's scripting API version, its embedded Python version, FL's pid and the pipe handle it holds, or an error saying what is missing. Call it first when a live tool (fl_exec, fl_call, fl_transport, project_write with open) fails, and after fl_install. Launches loopMIDI and FL when they are not running (launched_fl_seconds says how long FL took). Reads nothing from the project. Windows with FL Studio only.

fl_callA

Call one function of FL's scripting API inside the running FL and return what it returns: {ok, value} or {ok: false, error}. For a single read or change, e.g. a parameter name or a mixer level of the open project. Use fl_exec for several calls or logic; use project_read and project_write for anything the .flp file holds, which need no FL. A setter changes the open project as an edit by hand would; nothing is saved. Launches FL if needed. Windows with FL Studio only.

fl_execA

Run Python inside the running FL's embedded interpreter, where FL's modules (channels, mixer, plugins, transport, patterns, general ...) import. For live reads or changes that need several calls or logic; one call is simpler with fl_call. Returns {ok, value} with what the code assigns to result, or {ok: false, error} with the traceback. FL's sandbox refuses files, sockets and pipes. Changes act on the open project and are not saved. Launches FL if needed. Windows with FL Studio only.

project_readA

Read one FL Studio .flp file into JSON; FL need not run and the file is not changed. Use it to see what a project holds, to take parts from it, or to check what project_write wrote. For the style across many projects use profile; for the project open in FL right now, fl_exec. Views: 'summary' (start here: instruments, per-pattern stats, a per-track arrangement timeline, mixer effects); 'compact' (default: every note and clip as rows, the same shape project_write accepts; notes [bar, beat, tick, len_ticks, key, vel, instrument#], clips [track, bar, beat, tick, len_ticks, src, trim?] where src is a pattern id, s a sample, a an automation clip); 'full' (exact, round-trips byte for byte; large). Fails with the parser's error on a file that is not an .flp.

project_writeA

Write a project document to an .flp file, replacing any file at path. This is how a piece gets made.

The document: the compact form project_read returns, or its full form. The field reference is README.md, 'Project JSON, compact form'; examples/README.md has a working document per feature. Read one before a first write.

Sounds:

  • an instrument is a plugin by name (see plugins) with an optional preset, or a channel copied from a saved project, state {from: file, channel: n};

  • an effect is mixer.effects {track, slot, plugin} or one copied, {track, slot, from: {file, track, slot}}.

Units that are easy to get wrong: 96 ticks per beat, 4/4; keys like 'D#4' with MIDI 60 = C4; mixer volume 0.8 = 0 dB; a tempo automation value is (bpm - 60) / 120.

Without open, FL need not run. With open or play, FL first saves the project it has open (so no dialog appears), then opens this one.

Returns the file read back (channels, notes per pattern, clips per arrangement) and the writer's warnings; read them.

fl_renderA

Render an .flp to audio: a .wav and .mp3 beside it (replacing earlier ones), then spectrogram and stereo statistics, so the result can be read as numbers and pictures. Call it after project_write to check a piece. FL renders from the command line, so the FL that is open is saved first (path itself is restored if that save overwrote it) and closed. Runs detached and returns at once with the log file to read for the results and file names; a 2-minute piece takes under a minute. Windows with FL Studio only.

pluginsA

List the plugins this machine has: every plugin in FL's plugin database, and every tuned instance in the optional library project. Call it to choose instruments and effects before project_write; then presets for a plugin's presets, params for its automatable parameters. Each row: name, kind (instrument or effect), vendor, format (native, vst3, clap, vst), source (fl or library), how many presets load by name, whether it has a parameter map. Any of them goes into project_write by name: an instrument as {kind: plugin, plugin: , preset?, format?}, an effect as mixer.effects [{track, slot, plugin: , preset?, format?}]; without a preset it arrives as if dragged in fresh from FL's browser, a library instance as saved. A plugin installed in several formats is one name (native, then vst3, clap, vst unless format is given). Reads files only; FL need not run.

presetsA

List the presets that load by name for one plugin, as ids in catalog order; an id goes into project_write as an instrument's or effect's preset. Call it after plugins, when choosing a sound. Returns {plugin, kind, total, presets}; total counts every match even when limit cuts the list. A plugin name that matches nothing or several plugins returns {ok: false, error} naming the candidates. Reads files only; FL need not run.

paramsA

A plugin's automatable parameters, for writing automation: each one's index (the param of an automation target {channel: id, param: index} or {mixer: t, slot: s, param: index}), its name, and what its normalised value means where measured (FL's display at 0, .25, .5, .75 and 1, so a value can be picked for a wanted Hz, dB or %). Call it before automating a plugin or effect knob. It answers only for plugins with a parameter map (plugins shows which); for any other, read names live with fl_call('plugins.getParamName', ...). Not for choosing a sound: plugins lists what is installed, presets a plugin's presets. Reads files only; FL need not run.

fl_transportA

Play or stop whatever project is open in the running FL, to hear it; it changes nothing in any file. action 'play' jumps to the start and plays (from the start, not from where it stopped; called while playing, it restarts from the start). action 'stop' stops playback. mode 'song' plays the arrangement, 'pattern' loops one pattern (pattern: its number, selected first); without mode FL keeps the one it has. Launches FL when it is not running, but then nothing is open: open a project with project_write(open=true), which can also start playback itself (play='song'). Returns {playing, mode}. To get audio out, use fl_render, which saves and closes FL instead. Windows with FL Studio only.

profileA

List a person's projects from a folder of their .flp files; for one project's contents use project_read. Reads every .flp under the folder, subfolders included, and changes none of them; FL need not run; about 2 s for 80 projects. Returns a table of the projects: tempo, key, arrangement length in bars, so you know which to open and read in full with project_read; it decides nothing. Also written as profile.md and profile.json to tmp/profile//. Projects that fail to read are listed, not fatal; a folder with no .flp returns {ok: false, error}.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 13 tools

Disambiguation4/5

Most tools target distinct objects: plugins (installed plugins), presets (a plugin's presets), params (automatable parameters), project_read (one file), and profile (many files) are clearly separated. The main risk is fl_call vs fl_exec, both of which run code inside FL, but the descriptions explicitly frame fl_call as a single API call and fl_exec as multi-call logic, which mostly resolves it.

Naming Consistency3/5

There is a recognizable scheme — fl_* for live-link tools (fl_render, fl_install, fl_probe, fl_call, fl_exec, fl_transport) and project_* for file tools (project_read, project_write) — but the remaining tools are bare nouns (plugins, presets, params, profile, config) with no verb, so the set mixes prefixed-verb and plain-noun conventions. It stays readable and grouped, but not a single predictable pattern.

Tool Count5/5

13 tools is well within the healthy 3-15 range and each tool earns its place, covering distinct concerns (plugin discovery, presets, params, project I/O, rendering, profiling, config, install/probe, live API, transport). Nothing appears redundant or filler.

Completeness4/5

The surface covers the domain broadly: plugin/preset/param discovery, project read/write with sound and effect references, render to audio, multi-project profiling, config, live-link setup, live API access, and transport control. A few conveniences (e.g., dedicated sample/loop browsing or mixer/track editing outside project_write) are absent, but the core create-read-render-play lifecycle is closed.

Maintenance

ActivityNo data
ResponsivenessNo issues