Skip to main content
Glama
ryanpag3

coolercontrol-mcp

by ryanpag3

Create mode

create_mode

Save current settings of every channel as a named mode so the configuration can be restored later through activation.

Instructions

Save the current settings of every channel as a new mode, which activate_mode can restore later.

Input Schema

NameRequiredDescriptionDefault
nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description usefully adds that it captures live channel state rather than creating from scratch and that the result is restorable, but says nothing about name-collision behavior, whether an existing mode with the same name is overwritten or rejected, or what happens if a channel has no settings.

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?

A single sentence with no filler, front-loading the action and then the payoff. Nothing repeats the tool name or the annotations.

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

Completeness3/5

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

For a one-param create tool with safety annotations and no output schema, the core behavior is conveyed. Missing pieces that matter for correct invocation are name-conflict semantics and whether the newly created mode is returned/identifiable afterwards.

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

Parameters2/5

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

Schema description coverage is 0% and the single required 'name' parameter is never named or constrained in the description. It only implies a new mode gets labelled; agents get no signal about uniqueness, allowed characters, or whether an empty/duplicate name fails. With one obvious parameter the gap is moderate but real.

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?

States a specific verb+resource (save ... as a new mode) and adds scope the name alone doesn't convey: it snapshots 'the current settings of every channel'. It links forward to activate_mode, which separates it from sibling readers like list_modes/get_mode, though it does not disambiguate from duplicate_mode.

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 implied by 'save the current settings ... as a new mode' plus the note that activate_mode restores it later, giving an agent a sense of the snapshot/restore workflow. However, there is no explicit when-to-use statement and no guidance on when duplicate_mode or create_profile would be the better choice.

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