Skip to main content
Glama
Sign In
kuruitsugizaki

kuruitsugizaki

by whatanaiceguy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

project_write

DestructiveIdempotent

Write FL Studio project documents to .flp files, replacing any existing file at the given path. Use it to save notes, plugins, mixer, and automation, then optionally open or play the project.

Instructions

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. Mixer inserts run 1-125.

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.

Input Schema

NameRequiredDescriptionDefault
docYesthe project document, compact or full
openNoopen it in FL afterwards, launching FL if needed
pathYesthe .flp to write, absolute or relative to the repo; pieces go to projects/music/<piece>.flp
playNo'song' or 'pattern': open it and start playback

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.1
    • addedInput schema / properties / doc / description
      Added value: +"the project document, compact or full"
    • addedInput schema / properties / open / description
      Added value: +"open it in FL afterwards, launching FL if needed"
    • addedInput schema / properties / path / description
      Added value: +"the .flp to write, absolute or relative to the repo; pieces go to projects/music/<piece>.flp"
    • addedInput schema / properties / play / description
      Added value: +"'song' or 'pattern': open it and start playback"
  2. First observedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuine operational detail beyond them: the file at path is replaced, FL need not be running unless open/play is used, and FL first saves its currently open project before opening this one. The side-effect chain (launch FL, save existing project) is disclosed, which annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the destruction semantics, then organized into scannable sections (sounds, units, behavior, returns). Dense but each block is functional; the units section is arguably long but directly prevents common errors.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and nested input, the description covers return values ('the file read back... and the writer's warnings; read them'), input format and reference material, unit conventions, and open/play side effects. An agent has what it needs to construct a document and predict consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description meaningfully elaborates the complex nested doc parameter: compact vs full form, the 'sounds' shapes (instrument as plugin+preset, effect as mixer.effects or copied form). It also warns about easy-to-mistake units. This adds real value over the schema's terse 'compact or full' note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Write a project document to an .flp file, replacing any file at path.' This makes clear it is the write counterpart to project_read, and the follow-up 'This is how a piece gets made' frames the outcome an agent produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Given clear workflow context: 'Read one before a first write' points the agent to the README/example reference, and 'Without open, FL need not run' contrasts the open/play variants. It stops short of explicitly routing to sibling tools (e.g. project_read) by name, so 4 rather than 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools