Skip to main content
Glama
Sign In
LiveSession MCP

LiveSession MCP

by Uri-Rosen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

create_locator

Create a named cue point at a beat position in an Arrangement, renaming any existing locator within a small tolerance instead of toggling it off.

Instructions

Create a named locator (cue point) in the Arrangement at a beat position.

If a locator already exists at that beat (within ~1e-3 tolerance) it is renamed instead of toggled off. Time is in beats from the start of the arrangement (e.g. 0.0 = start, 16.0 = bar 5 in 4/4).

Parameters:

  • name: The locator label (e.g. "Chorus", "Verse 1", "Drop")

  • time: Beat position where the locator should sit

  • user_prompt: The original user prompt that led to this tool call (for telemetry)

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>",
      "time": "<time>"
    },
    "name": "create_locator"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
timeYes
user_promptNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses genuinely useful behavior: an existing locator at the same beat within ~1e-3 tolerance is renamed rather than removed, so the call is effectively idempotent and non-destructive. It does not cover permissions or error conditions, but the tolerance rule is the key non-obvious trait.

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?

Behavior comes first, then a compact parameter list — well front-loaded. The bullet list slightly duplicates the schema titles, but given zero schema description coverage it earns its place.

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

Completeness5/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, and the description covers units, collision behavior, and each input parameter. For a small write-scoped tool this is sufficient for an agent to call it correctly.

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?

With schema coverage at 0%, the description carries full burden and does so for all three parameters: name with example labels, time with the crucial unit explanation (beats from arrangement start, 0.0 = start, 16.0 = bar 5 in 4/4), and user_prompt as telemetry input. The units clarification is exactly the kind of meaning the bare schema cannot provide.

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 and resource with scope: 'Create a named locator (cue point) in the Arrangement at a beat position.' The parenthetical clarifies jargon. It does not distinguish itself from the sibling set_locator, which an agent could easily confuse with this tool.

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 through the rename-instead-of-toggle behavior, which hints at idempotent semantics, but there is no explicit guidance on when to use this vs set_locator, get_locators, or delete_locator, and no stated prerequisites (e.g. needing Arrangement view or an existing live 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