Write original songs with SoundBreak AI artists. Built with artists, not on them. Co-write in this chat, play a preview (not a release), and save to your SoundBreak account. Lyrics you wrote stay yours. After you save, you can submit to artists, SoundBreak Radio, or distribute (Spotify, Apple Music, and more) from SoundBreak.
Terms: https://app.soundbreak.ai/terms Privacy: https://app.soundbreak.ai/privacy-policy
Scored across 6 tools
Each tool targets a distinct resource and action: creating generations, polling status, listing artists, getting artist details, listing user songs, and removing previews. There is no meaningful overlap between tools, and related tools are clearly separated by purpose.
All tool names follow a consistent snake_case verb_noun pattern: create_, get_, list_, remove_. The pattern is predictable and makes the toolset easy to navigate.
Six tools is a well-scoped set for the stated domain of AI song generation, artist discovery, and preview management. Each tool earns its place without unnecessary redundancy.
The core generation lifecycle is covered: create, poll, list results, and remove previews. Minor gaps exist such as no cancel-generation or per-song detail endpoint, but the main user workflows are fully supported.
Start a SoundBreak song generation with an AI artist. ALWAYS pass the same end_user_id for this person (Dify: sys.user_id). Prefer artist_name from the user. Complimentary generations produce one song; a connected SoundBreak account defaults to two. After this returns, poll get_song_generation_status with generation_id and the same end_user_id until complete. There is no in-chat widget — share listen_url when ready. If end_user_id is missing, do not invent one.
| Name | Required | Description | Default |
|---|---|---|---|
| lyrics | No | Optional lyrics to use instead of AI-generated lyrics | |
| prompt | Yes | Song idea / creative direction only. Do not put take-count instructions here — set song_count instead. | |
| song_count | No | Pass 1 only if the user explicitly asked for one song / one take / not two. Pass 2 if they explicitly asked for two. Omit for ordinary requests like 'write me a song'. | |
| artist_name | No | Artist name from the user, e.g. "Kevin" or "Kevin Griffin". Preferred when the user names an artist. | |
| end_user_id | No | Stable per-person id for this caller. Required for complimentary gens and account linking. Dify: set Fixed from sys.user_id (string or number is fine). Pass the same value on every generate/status/library call. Do not invent a new id each turn. | |
| ai_cowriter_id | No | Artist id from list_artists / get_artist_details. Optional if artist_name is provided. | |
| instrumental_only | No | If true, generate instrumental music only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reveals important non-obvious behaviors beyond annotations: generation is asynchronous and requires polling, song count depends on account state (complimentary=1, connected=2), there is no in-chat widget, and end_user_id must stay stable and not be invented. No contradiction with readOnlyHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and every sentence carries an operational fact. It is slightly longer than necessary and repeats some end_user_id guidance already present in the schema, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description closes the execution loop: after the call, poll with generation_id and the same end_user_id until complete, then share listen_url. Combined with the detailed schema, an agent has enough to invoke the tool and follow up correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 7 parameters with descriptions, so the baseline is 3. The description adds cross-parameter meaning: reuse end_user_id on polling, prefer artist_name over ai_cowriter_id, and interpret song_count via account state. This adds real value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb ('Start') and a specific resource ('SoundBreak song generation'), with the AI-artist scope attached. This is immediately distinguishable from the read-only/list/status/removal siblings, so an agent knows this is the creation entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit operational guidance: pass the same end_user_id, prefer artist_name, poll get_song_generation_status after this returns, and share listen_url because there is no widget. It stops short of explicitly naming when-not situations or alternative tools, but the sequencing and conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific SoundBreak AI artist by ai_cowriter_id, including opener message and write URL. No user account required.
| Name | Required | Description | Default |
|---|---|---|---|
| ai_cowriter_id | Yes | The artist id from list_artists (ai_cowriter_id) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that no user account is required, which is useful context beyond the annotations. It doesn't describe the response format, but with no output schema, that's a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose, includes the key identifier, and mentions the included fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and full schema coverage, the description is nearly complete. It could mention the response format, but the annotations cover the safety profile and the schema covers the parameter. The 'no user account required' note adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameter. The description adds that the ID is from list_artists, which is helpful context, but doesn't add much beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details for a specific artist by ai_cowriter_id, and explicitly mentions the included fields (opener message and write URL). It distinguishes itself from list_artists by focusing on a single artist's details rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need details for a specific artist by ID, and the sibling list_artists provides the ID. It doesn't explicitly state when not to use it, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll a SoundBreak song generation until complete. Call after create_song_generation with generation_id and the same end_user_id. Keep calling while poll_again is true. Share listen_url only when generation_status is complete and ready_to_share is true. There is no in-chat widget.
| Name | Required | Description | Default |
|---|---|---|---|
| end_user_id | No | Stable per-person id for this caller. Required for complimentary gens and account linking. Dify: set Fixed from sys.user_id (string or number is fine). Pass the same value on every generate/status/library call. Do not invent a new id each turn. | |
| generation_id | No | 32-char hex generation_id from create_song_generation. Optional — omit to check the latest generation for this user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the polling loop semantics, the condition for sharing the listen_url, and the limitation of no in-chat widget. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. Purpose is front-loaded, followed by usage instructions and a limitation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a polling status tool, it explains the entire call loop, the conditions to act on the result, and a limitation. Though no output schema, it implies response fields (poll_again, generation_status, ready_to_share, listen_url) sufficiently for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description only reiterates using the same end_user_id and linking to create_song_generation, which adds minimal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Poll' and resource 'song generation', clearly distinguishing it from sibling tools like create_song_generation, list_my_songs, or remove_song_preview. An agent can immediately identify its role without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call after create_song_generation, pass the same end_user_id, keep polling while poll_again is true, and share listen_url only when generation_status is complete and ready_to_share is true. Gives precise sequencing and conditional behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active SoundBreak AI artists (cowriters) available for co-writing. No user account required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by stating 'No user account required,' which is a significant behavioral trait not captured in annotations, and by specifying 'active' artists, implying filtering behavior. These additions go beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main action is front-loaded, and the additional note about account requirements is separate and succinct. Everything earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description is nearly complete. It states what is listed and that no account is required. It does not describe the output shape, but with no output schema and a straightforward list resource, this is a minor gap; mentioning that returned artist IDs could be used with get_artist_details or create_song_generation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4 per the rubric. The description doesn't need to explain parameters, and it adds appropriate context (active, cowriters) that helps the agent understand what the returned list represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('active SoundBreak AI artists (cowriters)'), and the intended purpose ('available for co-writing'). It distinguishes itself from sibling get_artist_details by emphasizing it returns a list of available artists rather than details for one artist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: to find active AI artists for co-writing. It also mentions 'No user account required,' which sets an expectation about accessibility. However, it does not explicitly mention alternatives or exclusions, such as using get_artist_details for specific artist information, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent finished SoundBreak songs for this end_user_id. Use when the user asks what songs they made. Share listen_url only when ready_to_share is true. Those are preview links, not releases. Include user_notice verbatim and share remove_preview_url as a Remove preview markdown link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max songs to return (default 4) | |
| end_user_id | No | Stable per-person id for this caller. Required for complimentary gens and account linking. Dify: set Fixed from sys.user_id (string or number is fine). Pass the same value on every generate/status/library call. Do not invent a new id each turn. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds valuable behavioral context: that listen_url is a preview link, not a release, and that it should only be shared when ready_to_share is true. It also instructs to include user_notice verbatim and to format remove_preview_url as a markdown link, which are specific behavioral requirements beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose and usage, followed by specific handling instructions. Each sentence earns its place; however, it could be slightly tighter by merging some clauses. It is not bloated and reads clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with annotations covering safety, the description is complete. It provides specific instructions on how to handle the returned data (sharing preview links, including user_notice, formatting remove_preview_url), which addresses the lack of an output schema. An agent has everything needed to correctly invoke the tool and use its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (limit and end_user_id) are already documented with their meanings. The description only implicitly references end_user_id ('for this end_user_id') without adding new details. The baseline of 3 is appropriate since the schema carries the parameter semantics, and the description does not enhance them further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('List recent finished SoundBreak songs') and explicitly scopes it to 'this end_user_id'. It also states the intended use case ('Use when the user asks what songs they made'), which distinguishes it from sibling tools like get_song_generation_status (status) and remove_song_preview (removal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger context ('Use when the user asks what songs they made'), which is helpful for an agent to select this tool. It does not explicitly mention when NOT to use it or name alternatives, but the sibling list makes the distinction obvious. The instruction to share listen_url only when ready_to_share is true also guides conditional use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take down the public SoundBreak preview page for a song this user created. Does not delete the recording. Use when they ask to take a song down, remove the listen page, or unlist a preview. Pass revision_id (preferred) or revision_hash from listen_url. Songs on SoundBreak Radio or submitted for store distribution cannot be removed this way. After success, tell them the page is down, lyrics they wrote stay theirs, and the generated audio is kept only so it can be recognized if it shows up somewhere it shouldn't. Do not call this delete. Do not invent revision ids.
| Name | Required | Description | Default |
|---|---|---|---|
| end_user_id | No | Stable per-person id for this caller. Required for complimentary gens and account linking. Dify: set Fixed from sys.user_id (string or number is fine). Pass the same value on every generate/status/library call. Do not invent a new id each turn. | |
| revision_id | No | revision_id from the song in the current generation or list_my_songs | |
| generation_id | No | Optional 32-char hex generation_id to pin the song to this generation | |
| revision_hash | No | revision_hash from listen_url if revision_id is not available |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description adds meaningful behavioral detail: it does not delete the recording, lyrics remain the user's, and the generated audio is retained for recognition. This goes beyond the annotation flags and tells the agent what side effects to communicate after success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, non-destructive caveat, use cases, parameter selection, exclusions, post-success messaging, and a safety warning. It is front-loaded with the core action and then systematically covers the necessary details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description is complete: it explains what gets removed, what is preserved, how to identify the target revision, when removal is impossible, and how to frame the result to the user. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds selection semantics: 'Pass revision_id (preferred) or revision_hash from listen_url' and 'Do not invent revision ids.' This helps the agent choose between ambiguous identifiers, though generation_id is only explained by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Take down the public SoundBreak preview page for a song this user created.' It also distinguishes itself by clarifying 'Does not delete the recording' and warning 'Do not call this delete,' so an agent can clearly separate this from a true deletion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use when they ask to take a song down, remove the listen page, or unlist a preview.' It also gives concrete exclusions ('Songs on SoundBreak Radio or submitted for store distribution cannot be removed this way') and parameter selection guidance, so the agent knows exactly when and how to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_song_generationget_artist_detailsget_song_generation_statuslist_artistslist_my_songsremove_song_preview
Add one secure layer between your agents and this server.