suno-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.2
Disambiguation4/5
The creation tools are distinguished by their operation names and map to distinct Suno features, so an agent can usually select correctly. However, the descriptions are formulaic, and similar operations like create_mashup, stitch_audio, and extend_music could be confused without deeper API knowledge.
Naming Consistency5/5
All tool names use snake_case and most follow a clear verb_noun pattern such as add_samples, get_task, and check_pricing. The single verb-only name 'login' still fits the imperative style, so there is no meaningful inconsistency.
Tool Count5/5
At 15 tools, the server covers the full Suno/RunAPI surface without obvious padding; each creation operation, plus auth and status/pricing helpers, serves a distinct need. The count sits at the upper end of the ideal range but is justified by the broad feature set.
Completeness4/5
The tool set covers authentication, pricing, and the main Suno creation operations, plus task status retrieval. It lacks cancellation and list-tasks endpoints, but agents can still drive generation workflows end-to-end.
Average 3.2/5 across 14 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. The description mentions the return of task id, status, and URLs, implying an asynchronous pattern, but it does not explain the asynchronous behavior, polling, or whether the task is destructive. The schema hints at wait/timeout/polling, but the description does not connect these to the operational behavior, leaving the agent uninformed about side effects or execution flow.
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 a single sentence with no filler words. It is grammatically correct and front-loads the action and resource. However, given the tool's complexity, this brevity borders on under-specification rather than true conciseness. Yet, strictly by the dimension, it is efficient and free of extraneous content, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description must carry substantial weight. It tells the agent what the tool does and what it returns, but leaves out crucial context such as the purpose of 'inspire music' mode, how the audio URLs are used, the significance of the model versions, and any differences from the siblings. An agent cannot effectively decide or invoke this tool without further investigation.
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 67% (4 out of 6 parameters have descriptions, but timeout_ms and poll_interval_ms do not). Since coverage is not high (>80%), the description is expected to compensate, but it adds no parameter information at all. The only implicit reference is to audio_urls (as the required input), but it does not explain how they are used or their constraints (e.g., max 4 items). It falls short of the baseline 3 because the missing parameters remain 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 clear action ('Create a Suno task') and specific resource ('RunAPI' with 'inspire music' mode). It also mentions what it returns (task id, status, output URLs), which helps define its scope. However, it does not explicitly distinguish it from sibling tools that also generate music (e.g., text_to_music, cover_audio, create_mashup), so the differentiation is lacking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not state any prerequisites, exclusions, or when to prefer it over other music generation tools. The phrase 'inspire music' is ambiguous and not elaborated elsewhere. With 13 sibling tools in the same domain, this lack of contextual guidance is a major gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions return values (task id, status, URL) but omits critical behavioral aspects such as that this is a long-running asynchronous task, that the 'wait' parameter controls polling, or that it creates a new resource (a mutation). No safety profile, permission requirements, or side effects are disclosed, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It efficiently conveys the core purpose and expected output structure, achieving maximum conciseness without sacrificing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters including complex enums (stem_name has ~100 options), yet the description provides no context on how separation modes work, when to use 'wait' vs 'callback_url', or how output URLs are delivered. With no output schema and no annotations, the description is insufficient for an agent to confidently invoke this tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% because most parameters (type, wait, stem_name, callback_url, timeout_ms, poll_interval_ms) have their own descriptions in the schema. The tool description adds nothing about parameters beyond the schema, so it does not compensate for the 25% uncovered (task_id and audio_id are minimally described but are required and self-explanatory). Baseline of 3 is appropriate since the schema handles most semantics.
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 'Create a Suno task on RunAPI (separate audio stems)' which clearly identifies the verb (create), resource (Suno task on RunAPI), and function (separate audio stems). It unambiguously indicates what the tool does and distinguishes it from sibling tools that handle generation, lyrics, or mixing. However, it does not explicitly compare with other 'create task' possibilities, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention circumstances where separation is appropriate, nor does it explain prerequisites like needing an existing task_id or audio_id. Without any usage context or exclusionary notes, the agent is left to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a task is created and returns task id/status/output URLs, but it does not disclose async behavior, the wait default, terminal statuses, side effects, or permission requirements. This is insufficient for a task-creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, followed by the key return values. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, the one-sentence description leaves major gaps: no usage context, no task lifecycle details, no clarification of wait/polling behavior, and no explanation of the output URL semantics. It is minimally viable but far from complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 5 of 7 parameters (71% coverage), and the description adds no additional parameter semantics beyond the tool's purpose. The undocumented timeout_ms and poll_interval_ms are not explained, and the description does not clarify how source_task_id and audio_id relate to the stitching operation, so the description provides minimal added value.
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 uses a specific verb ('Create a Suno task') with a resource ('RunAPI (stitch audio)') and states return values (task id, status, output URLs), which distinguishes it from sibling tools like cover_audio or remaster_audio. However, it does not explain what 'stitch audio' actually entails beyond the operation name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_mashup or extend_music, and no prerequisites are mentioned (e.g., needing a completed source_task_id). The only usage context is the tool name, so an agent cannot confidently decide between this and sibling audio tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It tells the agent that a task is created and returns IDs and URLs, but it omits key asynchronous traits such as polling behavior, wait semantics, webhook notifications, or the fact that the returned task may be processed asynchronously. This is insufficient for an agent to anticipate side effects or lifecycle behavior.
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 a single sentence that gets directly to the point and front-loads the core purpose. It contains no redundant or vague filler. While it is sparse, it avoids wasted words and is easy to process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, no output schema, and no annotations, so the description should provide richer context about async behavior, return format, and operational details. It only states the basics: creates a task and returns some fields. This is incomplete for an asynchronous task creation tool with multiple undocumented parameters and no output schema to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover 80% of parameters, so the baseline is 3. The description itself adds no parameter-specific meaning. Two parameters timeout_ms and poll_interval_ms are left undocumented in the schema and description, but the high coverage leaves the core requirements clear enough.
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 clearly states a specific action: 'Create a Suno task on RunAPI (text to sound)' with an identifiable verb, resource, and scope. It also mentions the return value (task id, status, output URLs). However, it does not distinguish this from the sibling 'text_to_music' tool, so it is not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like text_to_music, generate_lyrics, or blend_lyrics. There are no exclusion criteria, prerequisites, or contextual hints about appropriate use. The description simply states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It states that it 'Returns a task id, status, and output URLs,' which conveys the immediate outcome. However, it does not explain asynchronous behavior (e.g., that 'wait' can be set to false), cost implications, authentication requirements, or side effects beyond task creation. This is partial transparency but lacks depth.
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 a single sentence, which is concise and front-loaded with the key action ('Create a Suno task'). It avoids redundancy and delivers the most critical information (purpose and return values) without wasted words. However, it is arguably too terse, missing elaboration that could improve clarity, but still earns a high score for efficiency.
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?
Given the tool has 8 parameters, no output schema, and no annotations, the description is somewhat incomplete. It does not explain what 'add samples' entails, how the sample range parameters interact, or the meaning of callback_url and poll_interval_ms. While the schema covers some semantics, the description alone is insufficient for an agent to fully understand usage nuances, but it does cover the essential purpose and return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, which is high. The description adds no parameter-specific details, but the schema already documents most parameters, including meanings for start_seconds, end_seconds, wait, etc. The missing parameters (timeout_ms, poll_interval_ms) are not mentioned, but the baseline of 3 is appropriate given the high schema coverage.
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 'Create a Suno task on RunAPI (add samples)' and mentions returning a task id, status, and output URLs. This clearly identifies the tool's purpose (creating a Suno task specifically for adding samples) and differentiates it from siblings like 'create_mashup' or 'cover_audio' by specifying the sampling context, though it doesn't explicitly contrast with other Suno task creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs. alternatives. It does not mention prerequisites, conditions, or references to sibling tools. The only implication is via the parenthetical '(add samples)', but no explicit or implicit 'use when...' context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Look up', which implies read-only, but does not explicitly state side effects, authentication requirements, rate limits, or response format. This is insufficient for an agent to fully understand the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core function without any wasted words. It is appropriately sized for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should explain return values and any other relevant context. It does not mention what the response contains, whether it is structured pricing data, or what happens with default parameters. The description is too sparse to be complete for a tool that will be invoked by an agent without prior knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (model and action), each with enums and explanatory text. The description does not add any extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and identifies the resource ('RunAPI pricing') with a clear scope ('suno model line'). It distinguishes this tool from sibling action tools like text_to_music and get_task, making it clear that this is a read-only pricing lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. It simply states what the tool does without explaining scenarios or contrasting with other tools. The only hint is the verb 'look up', which implies a read operation, but no explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the return payload shape: a task id, status, and output URLs. However, it does not explain that this likely runs asynchronously, that the 'wait' option controls polling, or that remote tasks may incur cost or produce partial results. These are meaningful behavioral gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence followed by a short return-value note. Every phrase earns its place: it identifies the operation, the target service, the product area, and the primary return values. No redundant language or filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, no annotations, and no output schema, one sentence is not enough to make this tool fully navigable. The description lacks context about required fields, async behavior, optional callbacks, and how this relates to get_task or check_pricing. It is especially inadequate for an agent seeking to invoke a complex task-creation endpoint correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has high description coverage at 89%, so the heavy lifting is already done by the schema. The description itself adds little parameter-level meaning beyond indicating that this is a cover-audio task. A baseline of 3 is appropriate because the schema is descriptive, but the description does not add extra context about required inputs such as upload_url and vocal_mode.
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 the core action clearly: 'Create a Suno task on RunAPI (cover audio).' It uses a specific verb and resource, and the parenthetical identifies the cover-audio use case, which helps distinguish it from sibling music-generation tools. However, it could more explicitly describe that the tool works from an uploaded audio URL, so it does not fully differentiate itself from related task-creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as text_to_music, remaster_audio, or blend_lyrics. No exclusions, prerequisites, or alternate-tool recommendations are provided. The description merely states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states that the tool 'Returns a task id, status, and output URLs,' which hints at an asynchronous task-based behavior. However, it doesn't disclose mutation/side effects beyond 'create,' permission requirements, rate limits, or the fact that `wait` defaults to true and controls polling. This leaves agents guessing about the operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the verb and resource. It is extremely concise with no filler, earning high marks for efficiency even though it sacrifices content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, no annotations, no output schema), the one-sentence description is insufficient. It mentions return values but fails to explain core usage patterns like specifying a source (task_id vs audio_id), the two parameter modes, or how this differs from sibling generation tools. The schema provides parameter semantics but not the overall context needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 91% of parameters, so the baseline is 3. The description adds no parameter-specific detail; it neither clarifies parameter interactions nor highlights the required `parameter_mode` or the mutually exclusive source identifiers. The schema's own descriptions carry the weight, so no deduction is needed.
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 uses the verb 'Create' and specifies the resource as 'Suno task on RunAPI (extend music)', which clearly indicates the tool's function and distinguishes it from sibling tools like text_to_music or cover_audio. However, it doesn't elaborate on what 'extend music' entails (e.g., extending an existing audio track), so it's not fully explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives such as cover_audio or remaster_audio. It doesn't mention parameter_mode, the need to provide a source identifier, or any exclusions. This is a significant omission given the 23-parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It states that the tool returns a task id, status, and result payload, which implies an asynchronous task model, but it does not explain side effects, blocking behavior, error handling, or any prerequisites. The lack of detail gives an agent insufficient awareness of execution semantics.
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 a single sentence with no fluff, front-loading the action and outcome. It is appropriately concise, though it sacrifices useful details for brevity; still, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, this description is too sparse. It fails to explain the asynchronous nature, the purpose of wait/timeout/callback parameters, the structure of the result payload, or any constraints. Siblings like generate_lyrics likely have richer contracts, and this description leaves too much to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (4 of 6 params have descriptions), so the baseline is moderate. The tool description itself says nothing about parameters, failing to clarify the two undocumented params (timeout_ms, poll_interval_ms) or how wait interacts with them. It adds no value beyond the schema, which is exactly the baseline scenario.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create a Suno task) and the specific resource/operation (blend lyrics), which is distinct from siblings like generate_lyrics and create_mashup. The verb 'create' and parenthetical 'blend lyrics' make the purpose unambiguous.
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?
The description implies the tool is for blending two lyrics (via 'blend lyrics') but provides no explicit guidance on when to use it over alternatives like generate_lyrics or create_mashup. No exclusions or when-not conditions are given, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of explaining behavior. It only reports that the tool returns a task id, status, and output URLs; it does not explain the asynchronous/task lifecycle, whether wait blocks, what callback_url does, or any side effects. This leaves notable behavioral uncertainty for an agent invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no fluff or repetition. It clearly names the operation, the resource, the target service, and the expected return shape, making every part earns its place. No distracting or redundant wording.
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?
This is a 17-parameter creation tool with no output schema and no annotations, so the description is too sparse to be fully complete. It conveys core join abstract and return shape, but omits important behavioral details such as wait/poll behavior, webhook usage, and how vocal_mode affects the creation. Parameter schema descriptions partially compensate, but overall description does not fill enough gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, with detailed property descriptions like 'Two audio URLs to mashup' and one starting description of surgical_mode. The description adds no parameter information beyond the schema, so the schema contains the semantic work. The baseline of 3 applies here.
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 clearly identifies the verb and resource: 'Create a Suno task on RunAPI' and explicitly labels it as 'create mashup'. It also states what is returned (task id, status, output URLs). However, it does not explicitly differentiate this tool from sibling tools like blend_lyrics or text_to_music, though the resource type makes it fairly clear.
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?
The phrase 'create mashup' implies the intended use case, and the task-creation context suggests when to invoke it. But there is no explicit when-to-use guidance, no mention of alternatives, and no exclusions or prerequisites, so usage guidance is only implied, not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully states the return payload (task id, status, result), but does not disclose asynchronous behavior, required authentication, or polling semantics. This is partial disclosure but leaves significant context to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences, front-loaded with the action and resource. Every word contributes: it states the operation, context (Suno/RunAPI), and return structure, with no redundancy.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description gives the basic purpose and return structure but lacks important context about async polling, parameter semantics, and usage boundaries. It is adequate for a high-level understanding but not fully complete for an agent to invoke correctly without inferring from schema.
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?
The description does not mention any parameters or their roles. With 60% schema coverage, two parameters (timeout_ms, poll_interval_ms) are undocumented in both schema and description, and the description adds no semantic meaning to the prompt, wait, or callback_url 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 clearly states the action ('Create a Suno task') and the specific function ('generate lyrics'), along with the return payload (task id, status, result). It distinguishes from siblings like text_to_music or blend_lyrics by focusing on lyric generation, though it doesn't explicitly name them.
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 phrase 'generate lyrics' but there is no explicit guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. The description does not mention when to prefer this over text_to_music or other Suno-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions fetching status and result payload but does not specify whether the operation is safe (read-only), how it behaves if the task is incomplete, or any rate limits or authentication needs. This is minimal transparency for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the core purpose. It is front-loaded with the action and resource, with no superfluous words or repetition.
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?
For a simple two-parameter fetch tool with no output schema and no annotations, the description is adequate but minimal. It explains the main outcome (status and result payload) but lacks details about expected response structure, polling behavior, or error conditions. Given the absence of annotations, a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (task_id and action) are fully documented in the schema. The description adds no additional parameter context beyond the schema, meeting the baseline of 3 for high coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Fetch the current status and latest result payload for a suno task.' It uses a specific verb ('Fetch') and resource ('suno task'), and distinguishes from sibling action tools (add_samples, text_to_music, etc.) by focusing on retrieval rather than creation or modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, such as after submitting an async task, or any exclusions or alternatives. It only states what it does, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does disclose that the tool creates a task and returns a task id, status, and output URLs, which hints at asynchronous task behavior. However, it does not explain side effects, cost implications, authentication needs, or what a terminal status means, so transparency remains partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary verb, resource, and expected return values. It wastes no words and is easy to scan. The concise structure leaves only the most important details visible.
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?
For a tool with 19 parameters and no output schema or annotations, the description is not fully contextual by itself. It does mention the return shape and the overall purpose, and the schema provides good parameter detail, so the tool is minimally viable for an agent. Still, it lacks guidance on parameter combinations, mode semantics, or operational expectations like async behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is approximately 89%, and the input schema already provides meaningful descriptions for most parameters. The tool description itself does not add much parameter-level detail beyond the schema, such as how vocal_mode interacts with lyrics or prompt. Since the schema already carries the burden, a baseline score of 3 is appropriate.
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 clearly identifies the tool's action: create a Suno task for text-to-music generation on RunAPI. It also states the key output (task id, status, output URLs). It does not explicitly contrast with sibling tools, but the phrase 'text to music' conveys the primary function well enough.
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?
The description implies when to use the tool—when a user wants music generated from text via Suno—but it does not provide explicit guidance about when to prefer it over alternatives like text_to_sound, generate_lyrics, or cover_audio. It is minimally useful but lacks explicit exclusions or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that it returns a task id, status, and output URLs, giving some insight into the outcome. However, it does not disclose async behavior, potential delays, error conditions, or side effects. Since annotations are absent, the description carries the full burden but provides minimal behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It clearly conveys the purpose and primary output without fluff.
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 a relatively simple tool, the description covers the essential purpose and return values. It lacks details such as async behavior or error handling, but given the presence of parameters like 'wait' and 'timeout_ms', the absence of such context is a minor gap. Overall, it is sufficiently complete for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes several parameters (wait, model, audio_id, callback_url, source_task_id) with meaningful descriptions. The tool's description adds no extra meaning beyond the schema, and the schema coverage is high (71%), so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a Suno task for remastering audio, which distinguishes it from other audio generation tools like text_to_music or cover_audio. The verb 'Create' and resource 'Suno task' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states what it does, without indicating use cases or conditions (e.g., when you have existing audio needing remastering). No explicit comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses opening a browser and saving a config file, but does not mention potential side effects (e.g., overwriting existing config, requiring user interaction) or error conditions (e.g., browser not available).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys all necessary information. It is front-loaded and contains no wasted words.
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 the tool has one optional parameter and no output schema, the description is fairly complete. It explains the authentication mechanism and output location. Could mention that the return value is not specified, but since no output schema exists, it is not strictly required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'force' is already clear. The tool description adds no additional context beyond what the schema provides. Since schema coverage is 100%, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool authenticates RunAPI via a PKCE login flow and saves the API key to a config file. It is specific about the verb (authenticate) and resource (RunAPI), and distinguishes itself from siblings which are music generation tools.
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?
No explicit guidance on when to use or not use this tool. However, the sibling tools are all music-related, so it's implied this is the sole authentication tool. Does not mention prerequisites or scenarios where login is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![suno-mcp MCP server](https://glama.ai/mcp/servers/runapi-ai/suno-mcp/badges/card.svg)](https://glama.ai/mcp/servers/runapi-ai/suno-mcp)

Score Badge

Copy to your README.md:

[![suno-mcp MCP server](https://glama.ai/mcp/servers/runapi-ai/suno-mcp/badges/score.svg)](https://glama.ai/mcp/servers/runapi-ai/suno-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/runapi-ai/suno-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server