Mooer Prime M2 MCP

Overview Schema Source Related Servers Discussions Admin

restore_preset

Destructive

Writes a .preset file or one bank preset into a pedal slot over USB, backing up the previous slot content and reading it back to verify the restore.

Instructions

Write a .preset file, or one preset of a bank JSON, into a pedal slot (USB). Replaces the slot: the previous content is backed up and the result is read back and verified.

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": {
      "file": "<file>",
      "preset": "<preset>",
      "confirm": "<confirm>"
    },
    "name": "restore_preset"
  }
}

Input Schema

Name	Required	Description
`file`	Yes	.preset or bank .json file
`preset`	Yes	Target slot
`confirm`	Yes	Must be true
`bank_index`	No	For bank files: which preset of the bank (default = same number as the target)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 4, 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 and readOnlyHint=false, so the safety profile is known; the description goes further by disclosing that the previous slot content is backed up and that the result is read back and verified, which materially lowers the perceived risk of the destructive write. It stops short of saying what happens on verification failure or where the backup lands.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the operation and its target front-loaded and the destructive consequence disclosed immediately after. Every clause carries information the agent needs.

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 destructive write with no output schema, the definition covers the critical points: what is overwritten, that a backup exists, and that the write is verified. Missing only failure-mode behavior and confirmation of the required confirm flag, which the schema handles on its own.

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 all four parameters are already documented, including the bank_index default. The description adds only the framing that a bank JSON contributes 'one preset of a bank', which mildly contextualizes bank_index but does not explain format, slot numbering, or file validation 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?

The description gives a specific verb and resource: writes a .preset file or a single preset out of a bank JSON into a numbered pedal slot over USB. That is concrete enough for an agent to distinguish it from slot-to-slot operations like copy_preset or save_preset, though it never names a sibling or states the file-source vs slot-source distinction explicitly.

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 only implied by the input shape: you have a file on disk and want its contents in a slot, whereas copy_preset/save_preset work from the pedal's own state. There is no explicit 'use this when / use X instead' routing, and no stated prerequisite about an active USB connection beyond the parenthetical '(USB)'.

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