ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Lexicon Note

lexicon_note

Record verbatim terms and map them to system terms, tracks, craft roles, and outcomes so you can understand and update how someone names musical parts.

Instructions

Record what the person called something, and what it means in ismail. said: their words, verbatim ("too clean", "the snare is boxy"). means: the system terms it maps to, a list or ';'-separated ("fx eq peak 400 Hz -3 dB on snare; analyze_timbre centroid"). craft: the role the word belongs to (composer, arranger, performer, sound designer, recording/mixing/mastering engineer, producer, dj, director, cinematographer, colourist, editor, choreographer, listener). outcome: open | worked | partly | missed, with why. Update an entry with id=... (means, craft, outcome, why); the words themselves never change. Words about the work only: never record emotion, mood or health. The file is local and shared by every session (lexicon_view shows where). Returns the entry and what the same words meant before. track: the part their words name ("the answer bass" is the track 'reese'). heard: the feedback round where they named that part after hearing it alone (feedback_page(parts=...)); only then is the name confirmed, checked against what they typed there. A name you inferred stays unconfirmed: ask them.

Input Schema

Name	Required	Default
`id`	No
`who`	No	user
`why`	No
`said`	No
`craft`	No
`heard`	No
`means`	No
`track`	No
`where`	No
`outcome`	No
`project`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.4.0Oct 26, 2026

addedInput schema / properties / heard

Added value: +{
+  "default": null,
+  "type": "string"
+}

addedInput schema / properties / track

Added value: +{
+  "default": null,
+  "type": "string"
+}

First observedv0.3.0Oct 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and discloses important traits: the file is local and shared by every session, updates cannot change the original words, the tool returns the entry and prior meanings, and unconfirmed inferred names must be checked with the user. It does not cover permissions, concurrency, or destructive/overwrite behavior in depth.

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 purpose is front-loaded, but the description is a dense run-on paragraph mixing field definitions, constraints, update behavior, return values, and confirmation workflow. Most content earns its place, yet it would be easier to scan with clearer structure.

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?

For an 11-parameter tool with no schema descriptions and no annotations, the description is substantially complete: it explains creation, updating, constraints, confirmation, and return behavior, and an output schema exists. The main gap is that three parameters (who, where, project) receive no explanation.

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 explains the key fields said, means, craft, outcome, why, id, track, and heard with examples and workflow context, but leaves who, where, and project undocumented.

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 states a specific verb and resource: recording what a person called something and what it maps to in the system. It clearly separates create from update with id=..., but it does not explicitly distinguish itself from siblings like lexicon_find or notes_write beyond mentioning lexicon_view for file location.

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 gives clear usage boundaries: record work-related vocabulary only, never emotion/mood/health, update existing entries with id=..., and only confirm a name after feedback_page(parts=...). It lacks explicit routing to alternative tools such as lexicon_find when looking up terms instead of recording them.

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

Deploy Server