Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Live Control

live_control

Move a mapped control by turning a knob the way the stage or an agent would, applying the value at once and logging it with its bar.

Instructions

Move a mapped control (what the stage sends when a knob turns; an agent can turn one too, the same way). value: 0..1, or the param's own units for a 'raw' map. Applies at once and is logged with its bar.

Input Schema

NameRequiredDescriptionDefault
valueYes
controlYes
projectYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description does disclose two useful behavioral facts: the change "applies at once" and is "logged with its bar." However, it omits permissions/auth, reversibility/undo behavior, error conditions, and other side-effect details expected for a live mutation tool.

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 short and front-loads the action before adding value semantics and behavior. The parenthetical is useful, though "with its bar" is cryptic and slightly reduces clarity.

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

Completeness2/5

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

An output schema exists, so return values need not be explained. Still, for a required-parameter live mutation tool with no annotations and 0% schema descriptions, the definition is missing too much: what project/control identify, when this is appropriate, and what guarantees apply to the immediate change.

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 coverage is 0%, so the description must carry parameter meaning. It explains the value parameter well (0..1 or the param's own units for a raw map) but leaves the required control and project parameters undefined beyond the loose phrase "mapped control."

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 action and resource: "Move a mapped control," and clarifies that this is what the stage sends when a knob turns. The purpose is clear, but it does not distinguish this tool from nearby siblings such as live_controls, live_map, stage_control_set, or stage_control_map.

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?

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It mentions that an agent can turn a mapped control "the same way," but does not say when to choose live_control versus live_controls, live_map, or stage_control_set.

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

Deploy Server

Other Tools