Skip to main content
Glama
Sign In
kuruitsugizaki

kuruitsugizaki

by whatanaiceguy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fl_install

DestructiveIdempotent

Installs the controller script and MIDI link that connect this folder to FL Studio's live project, replacing older copies. Run once per install and again after moving the folder, with FL closed.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

The annotations already declare mutation, destructiveness, and idempotency, and the description adds meaningful operational detail: it replaces an older controller script, conditionally creates and assigns a loopMIDI port, and explains registry-rewrite behavior. The note about FL being open and the returned midi guidance further reduces ambiguity.

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 main action and then uses a clear numbered structure for the two effects. Despite covering a complex install flow, every sentence carries useful operational information and there is 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 destructive, stateful setup tool with no output schema, the description is complete: it covers prerequisites, side effects, registry caveats, the returned fields, and the recommended next call. Nothing essential for correct invocation is omitted.

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?

The tool takes no parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it correctly focuses on behavior and return value instead.

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?

The description states a specific verb and resource: setting up the live link to FL. It immediately enumerates the two concrete setup actions, so the tool is distinguishable from fl_probe and other siblings.

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?

It gives explicit usage conditions: needed once per install and again after the folder moves, with the prerequisite to close FL first. It also names the follow-up tool fl_probe, so the agent knows the next step in the workflow.

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