Skip to main content
Glama
ntworm

Ableton MCP Server

scaffold_extension

Creates a template Ableton Extension project folder with SDK imports, package and manifest entry points, and bundled vendor tarballs for offline builds. No Ableton connection required.

Instructions

Create a template Ableton Extension project folder.

The scaffold produces an extension that follows the same shape as the repository's own AbletonMCPServer_Extension: it imports @ableton-extensions/sdk, declares dist/extension.js as the package entry in both package.json["main"] and manifest.json["entry"], and bundles via tsx build.ts. Vendor tarballs shipped with the package are copied locally into the new project so local SDK/CLI packages are used during build. In the acceptance report, offline_passed indicates a probe that runs without requiring a connection to Ableton Live.

Side effects: creates files on disk. No Ableton connection required. Example: scaffold_extension("MyEffect", output_directory="/tmp/ext") Edge cases: returns a status="error" JSON when vendor tarballs are missing or output directory is not writable; never raises during disk writes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
authorNontworm
output_directoryNo.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A3.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it declares disk side effects, states no Ableton connection is required, documents the error-to-JSON behavior, and guarantees it never raises during disk writes. This is unusually rich disclosure.

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?

Front-loads the purpose, then cleanly segments internals, side effects, example, and edge cases. The internal-producer detail is slightly verbose but earns its place for building a mental model; structure is sound.

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 filesystem-mutating scaffold with an output schema present, the description is complete: purpose, produced artifact shape, side effects, failure modes, and a concrete example are all covered, so no essential behavior is left to guessing.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. The example clarifies 'name' and 'output_directory' usage, but 'author' is never mentioned and no parameter is given explicit semantics, leaving one of three params entirely undefined.

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+resource: 'Create a template Ableton Extension project folder.' The purpose is unambiguous, but it never explicitly contrasts itself with the sibling build_extension, so an agent must infer the scaffold-vs-build distinction.

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?

Usage is implied through an example call and edge cases (missing vendor tarballs, unwritable output dir), but there is no explicit when-to-use or when-not-to-use guidance, and the natural alternative (build_extension) is never named.

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