mainstage-mcp

set_patch_settings

Change tempo, time signature, or transpose for an existing MainStage patch, and optionally remove the tempo setting.

Instructions

Change tempo, time signature or transpose of an existing patch.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "concert": "<concert>",
      "patch": "<patch>"
    },
    "name": "set_patch_settings"
  }
}

Input Schema

Name	Required	Description	Default
`patch`	Yes
`tempo`	No
`concert`	Yes
`transpose`	No
`remove_tempo`	No
`wait_seconds`	No
`time_signature`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 15, 2026

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full burden and does very little with it. It does not say whether changes persist to the concert file, whether they are reversible, what 'remove_tempo' does (erase the tempo entirely vs. leave it unchanged), or what 'wait_seconds' controls. For a mutation tool with zero annotation coverage this is a substantial gap.

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?

A single compact sentence with no filler and the key resource information front-loaded. It is under-specified rather than bloated, which is a completeness problem rather than a conciseness one.

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

Completeness2/5

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

With seven parameters, 0% schema coverage, no annotations, and no output schema, the definition does not give an agent enough to invoke the tool correctly. At minimum it should explain concert/patch addressing, the tempo-versus-remove_tempo interaction, and the units and bounds of the numeric settings.

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

Parameters1/5

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

Schema description coverage is 0% across seven parameters, and the description only names three of the editable settings without format detail (tempo units, time signature array semantics, transpose in semitones). Four parameters — patch, concert, remove_tempo, and wait_seconds — receive no explanation anywhere, and the interaction between tempo and remove_tempo is entirely opaque.

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?

The description states a specific verb plus resource ('Change ... of an existing patch') and enumerates the three editable settings, so an agent can distinguish this from siblings like create_song_patch or get_patch. It stops short of naming a specific alternative, but the purpose is unambiguous.

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?

The phrase 'of an existing patch' implies the patch must already exist, which is a useful precondition cue. However, there is no guidance on when to use this versus creating a patch, no mention of whether read-only inspection via get_patch should precede it, and no indication of what happens if the patch does not exist.

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

Deploy Server