Skip to main content
Glama
whatanaiceguy

kuruitsugizaki

by whatanaiceguy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fl_render

DestructiveIdempotent

Render an FL Studio .flp to WAV and MP3, then output spectrogram and stereo statistics so you can inspect the audio numerically and visually.

Instructions

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.

Input Schema

TableJSON 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.5/5.0
Behavior5/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 critical operational context: it replaces earlier outputs, saves the open FL project first, restores the path if saving overwrote it, closes FL, runs detached, and returns a log file. It also gives timing expectations and platform limits.

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

Conciseness5/5

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

The description is front-loaded with the render outcome, then usage, side effects, return behavior, timing, and platform constraints. Every sentence carries necessary operational information with 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?

For a complex, destructive, detached render tool with no output schema, the description explains what the call returns at once, how to read results via the log file, what files are produced, and key side effects. Nothing essential for correct invocation appears missing.

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 description coverage is 100%, so all three parameters are already documented in the input schema, including the key examples and the reopen default. The description does not add syntax or format details beyond what the schema provides, so the baseline of 3 is appropriate.

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: render an .flp to audio, producing .wav, .mp3, spectrogram, and stereo statistics. This distinguishes it from sibling tools like project_write, project_read, and fl_transport without requiring schema inspection.

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?

Explicitly says to call it after project_write to check a piece, and notes Windows with FL Studio only. It gives clear context and a prerequisite, though it does not name when-not to use it versus alternatives such as fl_transport.

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