ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Project New

project_new

Create a song project directory with tempo, bar length and grid offset, optionally inheriting the objective and lineage of an existing project so a derivative keeps its original intent.

Instructions

Create a new project directory. project: a bare song name ('my_song') makes it in the songs folder (config_get('songs')), as /my_song/proj, the song layout with build.py beside proj/ (every op opens a bare name there, or in the song's own folder for an older song with project.json there); a path ('./my_song', 'D:/elsewhere/my_song') is taken as given. offset_sec = time of bar 1 (match a reference's grid with analyze_grid). master_limiter: start the master chain with a safety limiter (-0.3 dB); False for a build that writes its own master chain, so the default does not sit ahead of it. objective: what this piece is for, in the person's words ("keep a listener asleep for 3 hours"); see project_set. derived_from: the project this one is a version of; its objectives and lineage are carried over, so a derivative keeps the intent it came from (intent provenance).

Input Schema

Name	Required	Description	Default
`bpm`	Yes
`name`	No
`project`	Yes
`objective`	No
`reference`	No
`offset_sec`	No
`length_bars`	Yes
`derived_from`	No
`beats_per_bar`	No
`master_limiter`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.3Oct 29, 2026
- addedInput schema / properties / master_limiter
```
Added value: +{
+  "default": true,
+  "type": "boolean"
+}
```
First observedv0.3.0Oct 3, 2026

TDQS

B3.2/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 explains filesystem placement, song layout, default master limiter behavior, and lineage carryover, but it does not disclose overwrite behavior, permissions, failure modes, or reversibility for a directory-creating mutation.

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?

The description is front-loaded and information-dense, with little wasted text. Some parenthetical path-layout explanations are complex and would be easier to scan as structured parameter notes, but the content generally earns its place.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return values need not be described. For a complex 10-parameter creation tool with no annotations, however, the description leaves important gaps around required timing parameters, the name/reference fields, and existing-directory behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 for all 10 parameters. It adds meaningful semantics for project, offset_sec, master_limiter, objective, and derived_from, but leaves bpm, length_bars, name, beats_per_bar, and the reference parameter largely or entirely unexplained, including two required parameters.

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 opens with a specific verb and resource: "Create a new project directory." It clearly distinguishes the creation action from project inspection or modification implied by siblings like project_info and project_set, though it does not explicitly name those alternatives.

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 by the tool name and the opening sentence, and some parameter guidance is provided. However, the description does not say when to use this versus project_set or project_info, nor does it state when not to create a project, such as when one already exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server