Skip to main content
Glama
Sign In
kuruitsugizaki

kuruitsugizaki

by whatanaiceguy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fl_render

DestructiveIdempotent

Render an FL Studio .flp project to WAV and MP3, then generate a spectrogram and short report for checking a piece after project_write.

Instructions

Render an .flp to audio: a .wav and .mp3 beside it (replacing earlier ones), then a spectrogram and a short report. Call it after project_write to check a piece. FL renders from the command line, so an FL the harness started is saved first and closed; an FL the user started is left alone and the render refused until they close it. Runs detached and returns at once; a 2-minute piece takes under a minute. Returns {ok, rendering, log, saved_open_project}. Then call render_report(path) until it stops saying the render is running, and make no live call (fl_exec, fl_call, fl_transport) before that: FL is closed while it renders.

Input Schema

NameRequiredDescriptionDefault
keyNothe key the piece is written in, e.g. 'F minor' or 'G#m'; the log then says how much pitch energy falls outside its scale
pathYesthe .flp to render
reopenNoopen the project in FL again when done

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / key
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "the key the piece is written in, e.g. 'F minor' or 'G#m'; the log then says how much pitch energy falls outside its scale",
+  "title": "Key"
+}
  2. Changed2 schema fields changedv0.2.1
    • addedInput schema / properties / path / description
      Added value: +"the .flp to render"
    • addedInput schema / properties / reopen / description
      Added value: +"open the project in FL again when done"
  3. First observedv0.2.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description's 'replacing earlier ones' is consistent with that. It adds substantial useful context – detached execution, timing, harness-saved-and-closed behavior, refusal when user FL is open, and the return shape – which is meaningful beyond annotations. However, several of these (return shape, follow-up loop) are more procedural than behavioral-safety disclosure, so a 3 is appropriate rather than the top of the range.

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?

Dense and front-loaded: the core action and artifacts come first, prerequisites and caveats follow. A few sentences are lengthy (the FL closed-while-rendering note), but every sentence carries operational information. Slightly long, but no filler.

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?

Although there is no output schema, the description spells out the return object {ok, rendering, log, saved_open_project} and the follow-up protocol (poll render_report until it stops saying rendering). For a detached, stateful render tool, an agent has everything needed to call it correctly and handle the async result.

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

Parameters3/5

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

Schema coverage is 100% and all three parameters are fully described in the schema (key, path, reopen), so the schema does the heavy lifting. The description does not add syntax or meaning beyond the schema for these parameters. Baseline 3 applies.

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?

Specific verb and resource (render an .flp to audio) plus the exact artifacts produced: .wav, .mp3 beside it, a spectrogram, and a short report. Clearly distinguishes itself from siblings by naming project_write, render_report, fl_exec, fl_call, and fl_transport with their relationship to this tool.

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

Usage Guidelines5/5

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

Explicitly says when to call it (after project_write to check a piece) and gives a negative constraint: make no live call (fl_exec, fl_call, fl_transport) before the render stops running. It also explains the refusal condition for a user-started FL instance, leaving no ambiguity about prerequisites.

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