Skip to main content
Glama
Sign In
ismail: agent DAW (MCP server)

ismail: agent DAW (MCP server)

by newsbubbles
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Track Model

track_model

Records the sources a track's sound is modeled on, including references, sample paths, or 'designed', plus how it was derived, so credits can distinguish used sources from consulted ones.

Instructions

Record what a track's sound is modeled on, shown by project_info and render, and read by credits to tell the sources a piece uses from the ones only consulted. on: the example it was measured from ('ref', 'ref:', 'sound:', a path (a file, or a folder of takes such as 'ref/birds/potoo'), or a note like 'kit comp_2 of the ref drums'), a list of them when the sound comes from several sources (['ref/a.ogg (quiet stretches)', 'ref/b.ogg']), 'designed' for a sound made on purpose (most electronic music), or '' to clear. A note after a path goes in brackets. by: how (an op, a song script, 'ear exam'). Fits record it themselves (instrument_fit apply_to_track, track_fit apply=True); mimic profiles, measured library voices and imported samples need nothing.

Input Schema

NameRequiredDescriptionDefault
byNo
onNo
trackYes
projectYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.4.0
    • addedInput schema / properties / on / default
      Added value: +null
    • addedInput schema / properties / on / title
      Added value: +"On"
    • removedInput schema / properties / on / type
      Removed value: -"string"
    • changedInput schema / required
      Previous value: -[
-  "project",
-  "track",
-  "on"
-]New value: +[
+  "project",
+  "track"
+]
  2. First observedv0.3.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that provenance is shown by project_info and render and read by credits, and that an empty string clears the model, but it does not address permissions, reversibility, or other mutation-side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense and not padded, but it is structured as a long, tangled sentence followed by fragments. The phrase 'Fits record it themselves' is awkward and the parameter guidance would be easier to scan as explicit bullets.

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?

The tool has an output schema, so return values need not be explained. For a provenance-recording mutation tool with no annotations, the description covers the key semantic domains, clearing behavior, and when recording is unnecessary, though it leaves permission and side-effect details unstated.

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?

Schema description coverage is 0%, so the description must compensate. It thoroughly explains the two non-obvious parameters, 'on' and 'by', including accepted forms, list usage, 'designed', and clearing with ''; project and track are only implicit but are conventional identifiers.

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?

The description gives a specific verb and resource: 'Record what a track's sound is modeled on.' It also explains the downstream consumers (project_info, render, credits), though the opening sentence is dense and not as immediately legible as it could be.

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 provides clear conditional guidance about when this is unnecessary: mimic profiles, measured library voices, and imported samples need nothing, while fits record themselves via instrument_fit or track_fit. It does not explicitly contrast track_model with credits as the read-side sibling, but the usage context is otherwise clear.

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