Skip to main content
Glama

plan_grid_envelope_pattern

Read-onlyIdempotent

Read current Live grid and generate exact on/off Session clip envelope steps for straight or triplet rhythms, including Beat Repeat, without Live edits; rejects misalignment.

Instructions

Read current Live grid and return exact on/off Session clip envelope steps for a straight or triplet rhythm, including Beat Repeat Repeat. No Live edits. Supply the exact native on/off values; set_clip_parameter_envelope validates the destination clip and parameter before any write. Rejects grid/bar misalignment.

Input Schema

NameRequiredDescriptionDefault
barsYes
gridYes
onValueYesNative parameter value during active steps.
offValueYesNative parameter value during inactive steps.
startBeatNoAbsolute Session clip beat offset; default zero.
activeStepsYesUnique 1-based active step numbers within each bar.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.1
    • removedOutput schema / additionalProperties
      Removed value: -true
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "properties": {
      +      "bars": {
      +        "type": "number"
      +      },
      +      "destinationTool": {
      +        "type": "string"
      +      },
      +      "grid": {
      +        "type": "string"
      +      },
      +      "nativeParameterValidation": {
      +        "type": "string"
      +      },
      +      "points": {
      +        "items": {
      +          "properties": {
      +            "time": {
      +              "type": "number"
      +            },
      +            "value": {
      +              "type": "number"
      +            }
      +          },
      +          "required": [
      +            "time",
      +            "value"
      +          ],
      +          "type": "object"
      +        },
      +        "type": "array"
      +      },
      +      "startBeat": {
      +        "type": "number"
      +      },
      +      "stateVersion": {
      +        "minimum": 1,
      +        "type": "integer"
      +      }
      +    },
      +    "required": [
      +      "stateVersion",
      +      "grid",
      +      "bars",
      +      "startBeat",
      +      "points",
      +      "destinationTool",
      +      "nativeParameterValidation"
      +    ],
      +    "type": "object"
      +  },
      +  {
      +    "properties": {
      +      "error": {
      +        "properties": {
      +          "message": {
      +            "type": "string"
      +          },
      +          "outcome": {
      +            "enum": [
      +              "unknown",
      +              "not_executed"
      +            ]
      +          }
      +        },
      +        "required": [
      +          "message",
      +          "outcome"
      +        ],
      +        "type": "object"
      +      }
      +    },
      +    "required": [
      +      "error"
      +    ],
      +    "type": "object"
      +  }
      +]
  2. Changed1 schema field changedv0.3.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "type": "object"
      +}
  3. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavior: that the tool performs no edits, that it rejects grid/bar misalignment, and that validation happens downstream in set_clip_parameter_envelope.

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?

Three tight sentences, front-loaded with the core action and scoping before the workflow and validation notes. Each sentence carries distinct information with little waste.

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?

An output schema exists, so return-value details needn't be restated, and annotations carry the safety profile. The description covers purpose, scope, preconditions, and the downstream write path, leaving only minor gaps like exact error semantics for misalignment.

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 67%, so the schema documents onValue, offValue, startBeat, and activeSteps. The description echoes 'native on/off values' and the rhythm types (straight/triplet), which loosely maps to grid and the value params but adds no format or constraint detail beyond the schema. Baseline 3 is appropriate.

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 opens with a specific verb and resource ('Read current Live grid and return exact on/off Session clip envelope steps') and scopes it to straight or triplet rhythms including Beat Repeat Repeat. It also implicitly distinguishes itself from the write-path sibling set_clip_parameter_envelope, so an agent can tell planning from writing without opening either schema.

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?

It clarifies this is a read/plan step ('No Live edits') and points to set_clip_parameter_envelope as the subsequent validating write, establishing a workflow. It also names a precondition ('Rejects grid/bar misalignment'), though it doesn't spell out a full when-not-to-use rule.

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