Skip to main content
Glama
Mooer Prime M2 MCP

Mooer Prime M2 MCP

by lucanenni

save_preset

Destructive

Saves the active preset's edit buffer to a chosen or current slot, optionally renames it, and backs up the target slot's previous content first.

Instructions

Save the active preset's edit buffer into a slot (default: the current one), optionally renaming it. The previous content of the target slot is backed up to the data directory first.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "save_preset"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoPreset name (ASCII, max 20); default = current name
presetNoTarget slot; default = active preset

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds genuinely new context: the previous slot content is first backed up to the data directory, which materially softens the destructive risk and tells the agent overwrites are recoverable. It still does not say whether the backup name is discoverable or how to restore it.

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 tight sentences; the action and default target come first, and the backup safeguard follows. No filler or redundancy.

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?

Covers the action, the default target, and the safety behavior, which is what an agent needs to call a two-optional-parameter mutation correctly; only the result of the rename/backup (return info) is left implicit, and no output schema exists to cover it.

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 coverage is 100% and both parameters are documented there with defaults and constraints (ASCII, max 20, slot 1-80). The description only restates the default target ('default: the current one'), adding no format or edge-case detail beyond the schema, so the 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?

States a specific verb and resource ('save the active preset's edit buffer into a slot') plus the optional rename, which cleanly separates it from sibling mutations like create_preset, copy_preset, and backup_preset.

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 description implies when to use it (persisting an edit buffer to a slot) but never names the alternatives an agent must choose between — create_preset, copy_preset, backup_preset, restore_preset — nor states exclusions such as when not to overwrite a slot.

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