SunoMCP

suno_create_persona

Creates an artist persona from an existing song's vocal style so you can reuse the same voice across future generations.

Instructions

Create a new artist persona from an existing audio's vocal style.

This saves the vocal characteristics from a generated song so you can reuse
that same voice style in future generations. Great for maintaining consistency
across multiple songs.

Use this when:
- You generated a song and love the voice
- You want to create multiple songs with the same vocalist
- You're building an album with consistent vocal style
- You want to save a unique voice for future use

Creation follows the API's pricing rules; the free listing/deletion policy
does not apply. Check current pricing before creating a persona.

After creating a persona, use suno_generate_with_persona with the returned
persona_id to generate new songs with that voice.

Returns:
    Persona ID that can be used with suno_generate_with_persona tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "audio_id": "<audio_id>",
      "name": "<name>"
    },
    "name": "suno_create_persona"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Name for this persona. Use a descriptive name that helps you remember the voice style. Examples: 'My Rock Voice', 'Soft Female Singer', 'Deep Male Baritone', 'Energetic Pop Vocalist'
`audio_id`	Yes	ID of the audio to use as the persona reference. This should be a previously generated song whose vocal style you want to save and reuse.
`vocal_end`	No	End time in seconds of the vocal segment to use from the audio.
`description`	No	Description of the singer's style. Examples: 'Warm and breathy female voice with jazz influences', 'Powerful male rock vocalist with raspy tone'
`vocal_start`	No	Start time in seconds of the vocal segment to use from the audio. Useful for isolating a specific vocal section.
`vox_audio_id`	No	Optional audio ID used to generate a new singer's style by combining with the main audio. Useful for creating hybrid vocal personas.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.5May 31, 2026
Removedv0.1.3May 24, 2026
First observedv0.1.0Apr 4, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does disclose notable behavior: creation is billed under the API's pricing rules, the free listing/deletion policy does not apply, and pricing should be checked beforehand. It also states the persona is persisted for future generations. It does not mention limits on persona count, whether the source audio must be one you generated, or how personas are later removed.

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 definition is front-loaded with purpose, then usage scenarios, then cost caveat, then follow-up tool. It is somewhat longer than necessary — 'Great for maintaining consistency across multiple songs' is largely redundant with the third and fourth bullets — but nothing is genuinely confusing.

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

Completeness5/5

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

For a six-parameter mutation tool with a 100% documented schema and an output schema, the description covers the remaining unknowns an agent needs: what the tool produces (a persona_id), what to do next, and the cost implication. Nothing required to invoke it correctly is missing.

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%, and each parameter already carries its own descriptive text and examples, so the schema does the heavy lifting. The description adds only procedural meaning — that audio_id should come from a generated song whose voice you want to keep. Baseline 3 is appropriate 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 first sentence gives a specific verb and resource ('Create a new artist persona from an existing audio's vocal style') and the second explains what a persona actually is — saved vocal characteristics for reuse. It does not differentiate against sibling creation tools such as suno_create_voice or suno_create_custom_model, so an agent must infer the boundary itself.

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?

An explicit 'Use this when' list gives four concrete scenarios (saved a voice you like, multi-song consistency, album work, archiving a unique voice), and the follow-up sentence routes the agent to suno_generate_with_persona with the returned persona_id. It stops short of naming when NOT to use it, e.g. versus suno_create_voice for a non-song-derived voice.

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

Deploy Server