q-sys-mcp

Set a control value

qsys_set_control

Modify a named control's value on a Q-SYS system. Optionally ramp the change over a specified number of seconds.

Instructions

Set a Named Control value, optionally ramped over a number of seconds (Control.Set). This MUTATES the running/emulated system.

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": {
      "name": "<name>",
      "value": "<value>"
    },
    "name": "qsys_set_control"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Named Control name
`ramp`	No	Ramp time in seconds (optional)
`value`	Yes	New value (number, string, or boolean)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Jun 22, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Explicitly states 'This MUTATES the running/emulated system', which is good. However, lacks details on side effects, value validation, or what happens if control doesn't exist. No annotations provided to supplement.

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: first states purpose, second warns mutation. No wasted words.

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?

No output schema or annotations. For a mutation tool, more detail on reversibility, constraints, or return behavior would be helpful. But it's adequate for a simple set operation.

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

Parameters4/5

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

Schema covers all parameters (100%). Description adds ramp context ('optionally ramped over a number of seconds') beyond schema. Name and value are straightforward.

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 clearly states the verb 'Set' and the resource 'Named Control value', specifying optional ramp. It distinguishes from siblings like qsys_get_control (read) and qsys_set_component (component-level), but could be more explicit about the scope of 'Named Control'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., qsys_set_component). No prerequisites, context for ramp usage, or error handling mentioned.

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

Deploy Server