Retrieve the project groove settings that clips follow—style, amount, grid, accent, lean, and humanize—plus which tracks play straight, so you can inspect or adjust timing policy.
The project groove every clip follows (unless its track opts out): style, amount, grid, accent, lean, humanize; and which tracks play straight.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.3.0Does 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 real domain context beyond that: the exact set of groove attributes returned (style, amount, grid, accent, lean, humanize) and the per-track opt-out semantics that determine whether a clip actually follows the groove.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the resource scope front-loaded and the field list trailing; nothing is wasted. The semicolon-and-parenthetical packing is slightly dense but still readable in one pass.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the burden of describing the return value and does so by naming the groove fields plus the track-level exception. It stops short of stating the response shape (a single groove object with a list of straight-playing tracks), which would have closed the last gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies and there is nothing for the description to clarify beyond the returned content, which it does list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource precisely (the project-level groove) and enumerates its fields, and the parenthetical 'unless its track opts out' plus 'which tracks play straight' separates it from groove_set_track. It never states the verb (read/return), relying on the name 'groove_get' to imply retrieval, which keeps it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the get/set naming family — nothing says 'use this to inspect current groove before changing it with groove_set' or when to prefer groove_set_track. An agent can infer this is the read-side of a groove pair, but the description provides no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.