Retrieves the current transport state—playing, paused or stopped—plus mode, active pattern, playhead position and tempo, so you can check where playback is before editing or controlling a project.
Playing, paused or stopped; pattern or song mode; the current pattern; the playhead position; the tempo.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | beats |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add real value by listing what state the call surfaces (transport state, mode, current pattern, playhead, tempo), effectively compensating for the missing output schema, but it never states that the operation is read-only/non-mutating nor what shape the response takes.
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?
One compact sentence with no wasted clauses, and every field listed earns its place. The tradeoff is that the semicolon list is not front-loaded with a leading verb/statement of intent, so the reader learns the payload before the purpose.
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?
For a simple, zero-required-parameter read tool with no output schema, describing the returned fields is the most important thing and it is done. Still missing are the read-only guarantee and the meaning of the 'unit' parameter, both of which an agent needs and neither annotations nor schema supply.
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?
Schema description coverage is 0% and the description never mentions the single 'unit' parameter (beats vs ticks, default beats). The enum values are partially self-explanatory in the schema, but the description does nothing to explain what the unit applies to — presumably the playhead position — which leaves a genuine gap.
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 enumerates the transport state fields returned (play/pause/stop, pattern/song mode, current pattern, playhead, tempo), which lets an agent infer this is a transport status read. However, it is a bare noun-phrase list with no verb or resource statement, so the agent must infer 'returns current transport state' rather than being told it.
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?
There is no when-to-use guidance, no mention of how it relates to siblings such as get_project_state, get_history, or the mutation tools play/pause/stop. The agent gets no explicit signal that this is the read counterpart to those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.