Skip to main content
Glama
shengchao73

MCP-Suno

by shengchao73
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

MCP-Suno

MCP (Model Context Protocol) server for Suno music generation API.

Features

  • Generate Lyrics: Create lyrics based on a description or theme

  • Generate Music: Create custom songs with lyrics, style tags, and model selection

  • Automatic Polling: Built-in polling mechanism for async task completion

Related MCP server: Suno Autopilot MCP

Installation

  1. Clone or download this repository

  2. Install dependencies:

npm install

  1. Set up your API key by creating a .env file:

cp .env.example .env

Edit .env and add your Suno API key:

SUNO_API_KEY=your_actual_api_key_here

Building

npm run build

Running

npm start

Or for development:

npm run dev

MCP Configuration

Add this server to your MCP client configuration:

{
  "mcpServers": {
    "suno": {
      "type": "stdio",
      "command": "node",
      "args": ["E:\\xxx\\xxx\\xxx\\suno-mcp-1313api\\dist\\index.js"],
      "env": {
        "SUNO_API_KEY": "your_api_key_here"
      }
      "timeout": 600,
    }
  }
}

Available Tools

generate_lyrics

Generate lyrics based on a description or theme.

Parameters:

  • prompt (required): Description or theme for lyrics (e.g., "dance", "love song", "epic battle")

Returns:

  • task_id: The task ID for tracking

  • title: Generated song title

  • lyrics: Full lyrics text

  • status: Task completion status

Example:

{
  "prompt": "a romantic sunset song about two lovers meeting"
}

generate_music

Generate music with custom lyrics.

Parameters:

  • prompt (required): The lyrics for the song in Suno format (with [Verse], [Chorus], [Bridge] tags)

  • title (required): Title of the song

  • tags (optional): Music style tags (e.g., "pop, upbeat, female vocals", "rock, energetic")

  • mv (optional): Model version (default: "chirp-v4")

Returns:

  • task_id: The task ID for tracking

  • songs: Array of generated songs with:

    • id: Song ID

    • title: Song title

    • tags: Style tags

    • audio_url: MP3 audio file URL

    • video_url: MP4 video file URL

    • image_url: Cover image URL

    • image_large_url: Large cover image URL

    • duration: Song duration in seconds

    • model_name: Model used

    • status: Generation status

    • lyrics: Full lyrics text

Example:

{
  "prompt": "[Verse]\nWalking down the street\nFeeling the beat\nMusic in my soul\nTaking control\n\n[Chorus]\nThis is my song\nSinging all night long\nFeel the rhythm\nMoving along",
  "title": "My Song",
  "tags": "pop, upbeat, electronic",
  "mv": "chirp-v4"
}

API Endpoints

This MCP server uses the following API endpoints:

  • Submit Lyrics: POST https://1313api.top/suno/submit/lyrics

  • Submit Music: POST https://1313api.top/suno/submit/music

  • Fetch Task: GET https://1313api.top/suno/fetch/{task_id}

Polling Behavior

The server automatically polls for task completion with the following settings:

  • Max Attempts: 60

  • Polling Interval: 3 seconds

  • Total Timeout: ~3 minutes

Tasks are polled until they reach SUCCESS or FAILED status, or timeout is reached.

Error Handling

The server returns error messages in the following format:

{
  "error": "Error message description"
}

Common errors:

  • SUNO_API_KEY environment variable is not set: API key not configured

  • Failed to submit lyrics generation: API request failed

  • Task failed: Generation failed on the server

  • Task timeout: Generation took too long

License

MIT

Available Tools

2 tools
generate_lyricsA

Generate lyrics based on a description or theme. Returns the generated lyrics with title.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesDescription or theme for the lyrics (e.g., "dance", "love song", "epic battle")

TDQS

A3.8/5.0
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 of behavioral disclosure. It does disclose the return value ('generated lyrics with title'), which is a positive trait, but it does not elaborate on output length, style constraints, or other behavioral nuances. It provides some transparency but not a comprehensive account.

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 concise: two short sentences that lead with the core action and then state the return value. There is no superfluous text, making it well-structured and easy to parse.

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 simple tool with one fully documented parameter and no output schema, the description covers the essential behavior (generates lyrics) and return format (with title). It is adequately complete for an agent to know what the tool does and what to expect, though it omits minor limitations or stylistic details.

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 fully documents the single 'prompt' parameter with 100% coverage and includes examples. The description's phrasing ('based on a description or theme') merely paraphrases the schema's description and adds no additional semantic value, so the baseline 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 clearly states the tool's action (generate) and resource (lyrics), and specifies the input as 'a description or theme.' It differentiates from the sibling tool 'generate_music' by focusing on lyrics rather than music, making 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 when to use the tool—when lyrics are needed—but does not explicitly state when to prefer it over the sibling 'generate_music' or provide any exclusions or alternative guidance. The usage context is inferred rather than spelled out.

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

generate_musicA

生成自定义音乐。返回生成的歌曲,包含音频URL、视频URL和封面图片。纯音乐模式下prompt留空,make_instrumental为true

ParametersJSON Schema
NameRequiredDescriptionDefault
mvNo模型版本 (默认: "chirp-v4",可选: "chirp-v4", "chirp-auk","chirp-bluejay","chirp-crow")chirp-v4
tagsYes音乐风格标签 (例如: "pop, upbeat, female vocals", "rock, energetic")
titleYes歌曲标题
promptNo音乐创歌词。纯音乐模式下留空。如果是歌词格式必须是Suno格式（包含[Verse]、[Chorus]、[Bridge]标签）
make_instrumentalNo是否生成纯音乐，不包含任何乐器声音。true表示生成纯音乐，false表示生成包含演唱的音乐。
gpt_description_promptNo是否使用GPT生成音乐描述。#灵感模式专用#,只要是灵感模式都用无论是否生成纯音乐

TDQS

A4.4/5.0
Behavior4/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 the output format (audio/video/cover URLs) and the special instrumental behavior. While it doesn't mention potential limitations or side effects, it covers the essential behavioral aspects for a generation 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, well-structured sentence that front-loads the main purpose and includes a critical usage tip. No redundant information; every word earns its place.

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?

Despite no output schema, the description explicitly names the returned fields (audio URL, video URL, cover image), which is essential context. It also covers key parameter relationships. Minor gap: no mention of model version behavior or when to use vs. generate_lyrics, but overall adequate for the tool's complexity.

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 100%, so baseline is 3. The description adds value by linking prompt and make_instrumental (instrumental mode requires empty prompt), and clarifying the inspiration mode for gpt_description_prompt. This goes beyond the individual schema descriptions.

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 'Generate custom music' and specifies return values (audio URL, video URL, cover image). This distinguishes it from the sibling tool generate_lyrics, which focuses on lyrics generation, making 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context, especially for instrumental mode (leave prompt empty, set make_instrumental to true). However, it does not explicitly contrast with generate_lyrics or specify when to choose this tool over alternatives, so it lacks explicit exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedgenerate_lyrics
    • First observedgenerate_music
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

generate_lyrics and generate_music have clearly distinct outputs: one returns text (lyrics), the other returns audio/video (music). Their names and descriptions make the separation unambiguous.

Naming Consistency5/5

Both tools follow the exact same 'generate_<noun>' pattern, using snake_case consistently. This creates a predictable and coherent naming convention.

Tool Count3/5

With only 2 tools, the server feels thin for a music generation service. While the tools cover core generation, the count is borderline and would benefit from additional management or status tools.

Completeness2/5

The server only offers generation, lacking any way to list, retrieve, or manage past generations. For a realistic workflow, agents need status checks or history access, making the surface significantly incomplete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers