ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Feedback Page

feedback_page

Create a local feedback page where a person reviews clips, pictures, or text and answers numbered questions by typing or recording voice notes; answers and transcripts save automatically.

Instructions

A feedback page for the person, on this computer: the items to look at or listen to, then numbered questions, each with a text box and (voice=True) a Record button. Everything they type is saved as it changes and every recording is saved as a file and transcribed in the background; when they reopen the page, their text, their recordings with players and the transcripts all come back. Written to /work/feedback// (manifest.json, answers.json, voice/), served by one shared local server on 127.0.0.1 (found or started here; it serves every round), and opened in their default browser, never an app's browser pane, which has no microphone. A song's proj/ (rebuilt by the song's build) writes its rounds in the song folder instead, songs//work/feedback//, so a rebuild never takes the answers. items: [{label, path}] for a clip (audio or video) or a picture, [{label, text}] for words; a bare path or string works too. questions: ['What do you hear first?', ...]. open=False only returns the link. Calling it again for the same round rewrites the page and keeps every answer. The page ends in a Send button: the person presses it when they have said everything (done.json in the round), and pressing it again after a late addition counts as a new send. feedback_wait(project, round) waits for that Send and returns the answers; feedback_read reads them at any time and says SENT or STILL WRITING first. Never ask the person to type "done". The page ends with the made-with-ismail footer and how the piece's sound was made (credits(format='footer'); footer=False leaves it off). Next to Send, 'Copy my answers' copies them as plain text, numbered as the questions, to paste anywhere. share=True also writes a standalone copy for a listener who is not at this computer (/share/: index.html and the clips beside it): host it anywhere they can open it (a page you publish, any static host). It needs no server and no write access: their typing and voice notes stay in their browser, and 'Send my answers' sends them back as a message (the share menu, or a copy to paste, with the voice notes as files); feedback_paste(project, round, text, files) reads that message into this round. parts=True (every part) or a list of track names adds a 'Name the parts' block: each part alone and in the mix at the bars where it stands out most (parts_bars long, cut from the latest render(stems=True)), and a box for the person's name for it. Use it in the first round of a song, and whenever a note's words could mean more than one part ("the bass" with a sub, a reese and a talking bass): you change the part they meant only once you share its name. feedback_read shows their names; lexicon_note(said=, track=, heard=) keeps each. moments=True puts a time strip and a 'Mark this moment' button (or the M key) under the first audio item (moments='' picks another): while it plays, the person marks anything that strikes them with tick boxes (love this, too much, which part) and their words. feedback_read lists each moment with its time and its bars on the song. Offer it for rounds on a whole song's structure. Reach for it whenever the person should answer questions by voice or by typing at the desk: notes on a cut, a mix, a set of shots or sketches, a round of choices, anything you would otherwise build a page and a server for.

Input Schema

Name	Required	Description	Default
`open`	No
`port`	No
`items`	No
`parts`	No
`round`	Yes
`share`	No
`title`	No
`voice`	No
`footer`	No
`moments`	No
`project`	Yes
`questions`	No
`parts_bars`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 26, 2026

TDQS

A4/5.0

Behavior5/5

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

With zero annotations, the description carries the whole burden and does so: it discloses exact write paths (<project>/work/feedback/<round>/ with manifest.json, answers.json, voice/), the shared 127.0.0.1 server, opening in the default browser (not an app pane, which lacks a mic), autosave and background transcription, and that re-calling for the same round preserves every answer. It also explains the round-completion marker (done.json), that a second Send after a late addition counts as a new send, and the no-server standalone share copy.

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

Conciseness2/5

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

All useful content sits in one enormous run-on paragraph dense with parentheticals, with no line breaks or bullets to let an agent scan for the parameter it needs. Length is defensible for a 13-param tool at 0% schema coverage, but the delivery is repetitive and hard to parse — front-loading the purpose is the only structural concession.

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?

Given 13 parameters, three optional blocks (parts, moments, share) and a full sibling workflow, the description covers nearly everything an agent needs to call it correctly, including directory layout and rebuild-safety. An output schema exists, so return values need no prose. The unexplained `port` and `title` parameters are the only substantive omission.

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 coverage is 0%, so the description must supply all parameter meaning, and it explains most of the 13: items accepts {label,path} or {label,text} or a bare path/string, questions takes a list of strings, open=False returns only the link, voice, footer, share, parts/parts_bars, and moments (true or a specific item label/path). Only `port` and `title` are left without any description, which is the main residual gap.

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 opening sentence names a concrete artifact — a local feedback page with items to review, numbered questions, text boxes and optional voice recording — which is a specific verb+resource rather than a restatement of the name. It also implicitly separates itself from siblings by naming feedback_wait, feedback_read and feedback_paste and their distinct roles. The core purpose is clear, though it is buried under a dense first sentence with a parenthetical aside.

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?

'Reach for it whenever the person should answer questions by voice or by typing at the desk' plus concrete examples (notes on a cut, a mix, a set of shots) gives explicit when-to-use context. It further routes the agent: feedback_wait blocks for Send, feedback_read reads at any time, feedback_paste ingests a share reply, and it warns 'Never ask the person to type "done"'. No explicit when-NOT-to-use case is given, keeping it below a 5.

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

Deploy Server