ableton-mcp

Overview Schema Source Related Servers Discussions Admin

enqueue_nks_generation_jobs

Destructive

Plan or enqueue explicitly selected eligible discovered presets in batches of up to 100 with a single-use confirmation, without generating or marking presets saved.

Instructions

Plan or enqueue only explicitly selected eligible discovered presets, in batches of at most 100, using a single-use confirmation. Serum 2 and Omnisphere are limited to their deterministic factory pilots until every pilot record is validated. Does not generate or mark any preset saved.

Input Schema

Name	Required	Description
`dryRun`	No	False executes with token and hash.
`planHash`	No	Plan hash.
`presetIds`	Yes	Exact preset IDs to enqueue; product-wide enqueue is not supported.
`productSlug`	Yes	Exact product slug.
`confirmationToken`	No	Single-use plan token.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.1Oct 23, 2026

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / anyOf

Added value: +[
+  {
+    "oneOf": [
+      {
+        "properties": {
+          "confirmation": {
+            "properties": {
+              "expiresAt": {
+                "type": "number"
+              },
+              "planHash": {
+                "pattern": "^[a-f0-9]{64}$",
+                "type": "string"
+              },
+              "token": {
+                "minLength": 1,
+                "type": "string"
+              }
+            },
+            "required": [
+              "token",
+              "planHash",
+              "expiresAt"
+            ],
+            "type": "object"
+          },
+          "dryRun": {
+            "const": true
+          },
+          "plan": {
+            "type": "object"
+          }
+        },
+        "required": [
+          "dryRun",
+          "plan",
+          "confirmation"
+        ],
+        "type": "object"
+      },
+      {
+        "properties": {
+          "dryRun": {
+            "const": false
+          },
+          "enqueued": {
+            "type": "integer"
+          },
+          "jobs": {
+            "type": "object"
+          }
+        },
+        "required": [
+          "dryRun",
+          "enqueued",
+          "jobs"
+        ],
+        "type": "object"
+      }
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error": {
+        "properties": {
+          "message": {
+            "type": "string"
+          },
+          "outcome": {
+            "enum": [
+              "unknown",
+              "not_executed"
+            ]
+          }
+        },
+        "required": [
+          "message",
+          "outcome"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  }
+]

Changed5 schema fields changedv0.3.0Oct 19, 2026

changedInput schema / properties / confirmationToken / description

Previous value: -"Short-lived, single-use token returned by the matching dry run."New value: +"Single-use plan token."

changedInput schema / properties / dryRun / description

Previous value: -"Omit or true to return a plan; false requires a valid confirmationToken."New value: +"False executes with token and hash."

changedInput schema / properties / planHash / description

Previous value: -"Hash returned by the matching dry run."New value: +"Plan hash."

changedInput schema / properties / presetIds / items / description

Previous value: -"Stable NKS preset catalog ID."New value: +"NKS catalog preset ID."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

Addedv0.2.0Sep 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the bar is lower, yet the description adds real value: single-use confirmation tokens, the 100-item batch ceiling, vendor-specific restrictions (Serum 2 / Omnisphere limited to factory pilots until validation), and an explicit non-effect ('Does not generate or mark any preset saved'). It stops short of explaining what happens to a plan if the token expires or jobs are partially enqueued.

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?

Three sentences, all load-bearing, with the core scope constraint front-loaded. Slight density in 'deterministic factory pilots' costs a bit of readability but nothing is redundant.

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?

An output schema exists, so return values need not be explained, and the annotations carry the safety profile. For a destructive, non-idempotent batch mutation the description covers the critical unknowns: batch ceiling, single-use confirmation, vendor gating, and the explicit statement that nothing is generated or marked saved.

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 dryRun, planHash, presetIds, productSlug and confirmationToken are already documented and the baseline is 3. The description reinforces the 100-item batch limit and the single-use token semantics but adds no syntax, format, or sequencing detail (e.g., how planHash and confirmationToken relate) beyond the schema.

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

Purpose4/5

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

States a specific verb and resource ('Plan or enqueue ... presets') and constrains scope to 'explicitly selected eligible discovered presets,' which separates it from worker-side siblings like claim_nks_generation_job and complete_nks_generation_job. It never names those siblings explicitly, so the differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

It gives eligibility and batching constraints ('explicitly selected eligible,' 'batches of at most 100') and mentions single-use confirmation, which implies a plan-then-execute flow. However it never states when to use dryRun planning versus execution, nor routes the agent to get_nks_generation_status or claim_nks_generation_job alternatives. Usage is implied, not prescribed.

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

Deploy Server