Skip to main content
Glama
Sign In
kuruitsugizaki

kuruitsugizaki

by whatanaiceguy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

presets

Idempotent

Lists a plugin's sound IDs by name so you can choose a sound and pass its id to project_write; supports query filtering and optional harvesting of built-in sounds.

Instructions

List the presets that load by name for one plugin; 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, and when there are more than limit the list is an even spread across the preset folders, each folder an equal share, not the first ones. A plugin name that matches nothing or several plugins returns {ok: false, error} naming the candidates. Reads files only and FL need not run, except with harvest, which opens the plugin in FL and adds its built-in presets to the catalog.

Input Schema

NameRequiredDescriptionDefault
kindNo'instrument' or 'effect', for a name that is both (Serum2); without it the instrument is taken
limitNoat most this many ids
queryNowords that must all appear in the id, case-insensitive, any order, e.g. 'bass reese'
pluginYesthe plugin's name as plugins lists it; a unique part of it works
harvestNofirst read the plugin's built-in presets from FL (opens it there once, about a second per preset); for a plugin whose presets live inside it, not in files

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.5
    • changedInput schema / properties / query / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Changed2 schema fields changedv0.4.0
    • addedInput schema / properties / harvest
      Added value: +{
+  "default": false,
+  "description": "first read the plugin's built-in presets from FL (opens it there once, about a second per preset); for a plugin whose presets live inside it, not in files",
+  "title": "Harvest",
+  "type": "boolean"
+}
    • addedInput schema / properties / kind
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "'instrument' or 'effect', for a name that is both (Serum2); without it the instrument is taken",
+  "title": "Kind"
+}
  3. Changed3 schema fields changedv0.2.1
    • addedInput schema / properties / limit / description
      Added value: +"at most this many ids"
    • addedInput schema / properties / plugin / description
      Added value: +"the plugin's name as plugins lists it; a unique part of it works"
    • addedInput schema / properties / query / description
      Added value: +"words that must all appear in the id, case-insensitive, any order, e.g. 'bass reese'"
  4. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the return shape, that total counts all matches, that limit produces an even spread per preset folder rather than a truncated prefix, the {ok:false, error} result for ambiguous/unknown plugin names, and that harvest opens the plugin in FL at ~1s per preset. This also explains why readOnlyHint=false despite the otherwise file-only read.

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?

Purpose and caller order come first, then return shape, then paging semantics, then failure mode, then the harvest caveat. Dense but every sentence carries information an agent would otherwise have to discover by error.

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?

With no output schema, the description supplies both the success payload keys and the error payload, states the FL-runtime caveat for harvest, and covers the ambiguous-plugin failure. Nothing needed to call this correctly is missing.

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 the baseline is 3; the description still adds value by explaining what the returned id is consumed by and how a plugin name that matches several plugins fails with named candidates. Parameter-level details (kind, query, limit) are left to the schema.

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 + resource (list presets for one plugin) plus the downstream consumer ('an id goes into project_write as an instrument's or effect's preset'), which tells an agent exactly what the output is for. It also names the ordering dependency on the 'plugins' sibling, so it is clearly distinguishable from others in the set.

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?

'Call it after plugins, when choosing a sound' gives an explicit sequencing rule and trigger condition, and the harvest note says when the harvest variant applies (presets living inside the plugin, not on disk). No explicit when-not or comparison to the adjacent 'samples' sibling is given, which keeps it short of a 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