Skip to main content
Glama
pimvanoerle

sclang-mcp

by pimvanoerle
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

sc_render

Render SuperCollider code offline to a WAV file without audio hardware, then get peak and RMS stats to detect silence or clipping.

Instructions

Render SuperCollider code to a WAV file offline (faster than realtime, no audio hardware needed) and report level stats. The code runs in sclang and must provide what to render in one of three ways: ~pattern = Pbind(...) (or return a Pattern as the last expression); ~score = Score([...]) for raw server messages. Optionally set ~defs = [SynthDef(\name, {...}), ...] for any custom instruments the pattern uses (a basic \default instrument is always included). Use SynthDef objects without .add/.store. Example: ~defs = [SynthDef(\pluck, { |out=0, freq=440, amp=0.2| Out.ar(out, Pluck.ar(WhiteNoise.ar, 1, 0.1, freq.reciprocal, 3) ! 2 * amp * EnvGen.kr(Env.perc(0.01, 2), doneAction: 2)) })]; ~pattern = Pbind(\instrument, \pluck, \degree, Pseq([0, 2, 4, 7], 2), \dur, 0.25); The result includes peak/RMS so you can tell silence or clipping without listening. Returns the WAV path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesSuperCollider code (see tool description).
nameNoFile name without extension.render
tailNoExtra seconds rendered after the content so releases and reverbs can ring out.
durationYesLength of the musical content in seconds.
sampleRateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/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 substantial work: it explains the required code contract (~pattern, ~score, ~defs), that a basic \default instrument is always included, that SynthDefs must be used without .add/.store, and that results include peak/RMS to detect silence or clipping and return a WAV path. It still omits where on disk the file lands, overwrite/collision behavior, and error handling.

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?

The purpose is front-loaded in the first sentence, and the code contract plus example follow in a logical order. The escaped-quote example is long but earns its place for a DSL-driven tool, though it makes the block somewhat dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must cover returns, and it does ('returns the WAV path', peak/RMS stats). Combined with the code contract instructions, an agent has what it needs to invoke this correctly; only disk destination and lifecycle details are 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 80%, so the baseline is 3, but the description meaningfully enriches the most important parameter by spelling out the three accepted code shapes and providing a full working example. That adds real meaning beyond the schema's terse 'SuperCollider code (see tool description).'

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 SuperCollider code to a WAV file — plus the key distinction that it runs offline and faster than realtime. The parenthetical '(faster than realtime, no audio hardware needed)' implicitly separates it from the realtime sc_play sibling, so an agent can pick correctly without opening the schema.

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?

The offline/faster-than-realtime framing gives clear context for when this tool is the right choice over realtime playback. It does not explicitly name sc_play/sc_stop or state exclusions, so it stops short of full when/when-not guidance, but the context is unambiguous.

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