Skip to main content
Glama

mcp_opendaw_set_script_param

Set a scriptable device parameter by label with automatic validation and clamping to the declared range and type.

Instructions

Set a parameter value on a scriptable device by label.

The parameter must exist (created from a // @param declaration in the code). The value is validated against the declaration's range (min/max) and mapping type:

  • bool: snaps to 0 or 1

  • int: rounds to nearest integer within [min, max]

  • linear/exp/unipolar: clamps to [min, max] Response includes clamped flag and range info if the value was adjusted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYes
unit_indexYes
device_typeYes
param_labelYes
device_indexYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations are provided, but the description fully covers behavior: value validation against declaration's range, snapping/clamping per type (bool, int, linear/exp/unipolar), and response includes clamped flag and range info. This is highly transparent.

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?

The description is well-structured with the purpose at the start, followed by necessary details on validation. It is slightly lengthy but each sentence serves a purpose; no wasted words.

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?

Given the lack of schema descriptions and annotations, the description covers the core behavior and response content ('clamped flag and range info'). It does not explain all parameters but is sufficient for an agent to use the tool correctly.

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 0%, meaning no parameter explanations in the schema. The description adds value by explaining the value parameter's validation rules, but does not explain device_type, unit_index, device_index, or param_label. It partially compensates but not fully.

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?

The description clearly states the verb 'Set' and resource 'parameter value on a scriptable device by label'. It is specific and distinguishes from other set_* tools by focusing on scriptable device parameters.

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

Usage Guidelines4/5

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

The description explains that the parameter must exist from a @param declaration and details validation behavior per type. However, it does not explicitly state when not to use this tool or provide direct comparisons to alternatives, though the context implies it is for scriptable devices.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AMEOBIUS-team/opendaw-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server