ismail: agent DAW (MCP server)

Overview Schema Source Related Servers Discussions Admin

Credits

credits

Document all media sources and authorship for your music project. Automatically generates a CREDITS.md file detailing samples, models, and licenses used in each track.

Instructions

Write the piece's credits (CREDITS.md at the song root) from its SOURCES files (the recording, who made or played it, the licence, the link; columns about approval, local paths, dates and notes are left out), each track's model (measured from what, or designed) and its lineage (derived_from). Only the sources the piece uses are credited: a row is used when a track's model names its file, its folder or its id (track_model), a mimic profile or a sample came from it, or its table has an 'in the song' column saying yes. consulted=True adds the rest under 'Also consulted'. A plain list that repeats a table's rows (a SOURCES.txt of video ids) is left out. It says whether the piece holds any recorded audio (imported samples, audio clips) or only measurements rebuilt by synthesis. Files in ref/ with no SOURCES row are not credited: the reply lists them. Review the file before it goes public. out: another path; overwrite: replace an existing file (it may have been edited by hand). format='footer' writes nothing and returns the footer a page people may share ends with (ledger:M254): made with ismail, the link, and how the sound was made, by counts only (no names, no paths), as text and as HTML. Reach for it whenever you build a listening page or post by hand: every page a person may pass on ends with it.

Input Schema

Name	Required	Default
`out`	No
`format`	No	md
`project`	Yes
`consulted`	No
`overwrite`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 26, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description carries the full load and does so: it explains file creation, overwrite risk ('may have been edited by hand'), footer's write-nothing behavior, and that uncredited ref/ files are listed in the reply. This is rich behavioral context beyond what the schema provides.

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?

Front-loads the core write operation and each clause adds operational detail, but the single dense paragraph is longer than necessary and includes layered caveats. Still structured and mostly earns its length.

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

Completeness5/5

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

For a 5-parameter, no-annotation, output-schema-bearing tool, the description supplies enough context to call it safely, including side effects, exclusions, and footer return. The only minor gap is the lack of an explicit project parameter definition.

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 explain the parameters. It covers out, overwrite, format='footer', and consulted=True, but does not explicitly define the required 'project' parameter; hence 4.

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?

States a specific verb ('Write') and resource ('the piece's credits / CREDITS.md at the song root') and describes the inputs it draws from. It is clear, but it never explicitly differentiates from the sibling request_credits, so 4 rather than 5.

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?

Gives a concrete trigger for footer mode ('Reach for it whenever you build a listening page or post by hand') and a caution ('Review the file before it goes public'). It does not name alternatives or state when not to use it, so no 5.

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

Deploy Server