Skip to main content
Glama
wushiray

cakewalkmcp

by wushiray
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

cw_cal_run

Runs a CAL program in Cakewalk SONAR to create, delete, or read MIDI notes on a free build, stopping at the open dialog and reporting required accessibility steps.

Instructions

Write a CAL program into the folder SONAR reads, select everything, and open 处理 > 运行 CAL 程序 (0x806A). CAL needs no licence, so this is how notes get CREATED, DELETED or READ on a free build — the edit dialogs cover only transformation. This process cannot click, so it stops at the open dialog and reports the exact steps an accessibility runtime must take. The script ends with a modal pause that has to be dismissed, and CAL reports only a count — prove the effect by exporting and parsing.

Input Schema

NameRequiredDescriptionDefault
muteNoFor setTrackMute: true mutes, false un-mutes. TrackActive TRUE means AUDIBLE — the shipped script comments it as "Un-mute the track".
nameNoFor renameTrack: the new track name. Quotes and backslashes are stripped, since CAL has no escape syntax in any shipped script.
portNoFor setTrackRouting: output port.
backupNoWrite a .bak beside the script file before overwriting it.
maxKeyNo
minKeyNo
channelNoFor setTrackRouting: forced MIDI channel, 1..16.
confirmNodeleteNotes requires the exact token "deleteNotes".
percentNo
programYesWhich generated program to run. queryNotes RENAMES the track as its output channel, so it needs allowRename.
velocityNo
intervalsNo
semitonesNo
trackIndexNoFor the track programs: which track, 0-based. CAL counts project tracks from 0; an exported .mid puts the conductor first, so CAL track N is export track N+1.
allowRenameNoqueryNotes works by writing its summary into the track name, which modifies the project. Set this to accept that. For reading note data with no side effect, export to .mid and use cw_read_midi_file instead.
selectFirstNoPost 编辑 > 选择 > 全部 first. The CAL body runs once per selected event, so without a selection these programs do nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.3/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: the process cannot click, it halts at the open dialog, an accessibility runtime must take over, a modal pause must be dismissed, and CAL returns only a count so the effect must be proven by export and parse. These are exactly the non-obvious traits an agent would otherwise discover by failing.

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?

Four dense sentences, front-loaded with the mechanical action before the constraints and the verification strategy. Every sentence carries information, though the modal-pause and count-reporting points could be tightened into one clause.

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?

For a 16-parameter, no-output-schema tool this covers the essentials: the human-in-the-loop stop, the required dismissal step, and how to verify results without a return value. It leaves the overwrite/backup behavior and the destructiveness of deleteNotes to the schema rather than restating them.

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 63%, which is mid-range, and the description adds almost no parameter meaning of its own beyond implying the select-all step that maps to selectFirst. The important parameters (program enum, allowRename, confirm, backup) are documented in the schema, not here, so baseline 3 applies.

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 and resource: 'Write a CAL program into the folder SONAR reads, select everything, and open 处理 > 运行 CAL 程序 (0x806A)'. It also draws the boundary against the edit dialogs ('the edit dialogs cover only transformation'), so an agent can distinguish it from cw_edit and the cw_cal_* family without opening schemas.

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?

States a clear when-to-use: CAL is how notes get CREATED, DELETED or READ on a free build because the dialogs only transform. It does not explicitly name cw_cal_plan or cw_cal_help as the alternative for planning/diagnosis, and excludes nothing by name, so it stops short of full routing guidance.

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