Skip to main content
Glama

suno_generate_with_persona

Generate new songs with a saved artist persona to maintain consistent vocal style across tracks. Provide a persona ID and a music prompt to reuse a preferred voice for albums or series.

Instructions

Generate music using a saved artist persona for consistent vocal style.

This allows you to maintain a consistent voice/singing style across multiple
songs by using a previously saved persona.

Use this when:
- You want multiple songs with the same vocal style
- You're creating an album or series with consistent vocals
- You found a voice you like and want to reuse it

First create a persona with suno_create_persona, then use its ID here.

Returns:
    Task ID and generated audio information with the persona's voice applied.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoModel version to use.chirp-v5-5
promptYesDescription of the music to generate. The persona's voice will be applied to this new song.
audio_idYesID of a reference audio to base the generation on.
persona_idYesID of the persona to use. Get this from suno_create_persona tool. The persona defines the vocal style and characteristics.
callback_urlNoWebhook callback URL for asynchronous notifications. When provided, the API will call this URL when the audio is generated.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.18
    • changedInput schema / properties / model / enum
      Previous value: -[
      -  "chirp-v3-0",
      -  "chirp-v3-5",
      -  "chirp-v4",
      -  "chirp-v4-5",
      -  "chirp-v4-5-plus",
      -  "chirp-v5",
      -  "chirp-v5-5"
      -]New value: +[
      +  "chirp-v6",
      +  "chirp-v6-wild",
      +  "chirp-v6-mini",
      +  "chirp-v3-0",
      +  "chirp-v3-5",
      +  "chirp-v4",
      +  "chirp-v4-5",
      +  "chirp-v4-5-plus",
      +  "chirp-v5",
      +  "chirp-v5-5"
      +]
  2. Addedv0.1.5
  3. Removedv0.1.3
  4. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are declared, so the description carries the full burden of behavioral disclosure. It does reveal that the operation is an async-style generation that returns a Task ID and applies the persona's voice, and that it re-uses a previously created persona. It omits behavior details such as credit usage, how long tasks run, failure modes if the persona is invalid, or whether the reference audio is mixed -- are significant gaps for a music generation API with zero annotation support.

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 purpose is front-loaded and the 'Use this when' lists plus the prerequisite note come early, so an agent gets the gist quickly. Only minor redundancy: the second paragraph ('This allows you to maintain a consistent voice...') restates the lead sentence about consistent vocal style. The overall length is still justifiable and well-bulleted.

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?

The description stipulates the workflow, the intended use, and the async Task/audio return, while an output schema exists to cover return values in a structured way. The noteworthy missing part is distinguishing this from the nearest sibling, suno_generate_with_persona_vox, and no mention of authenticity or quota effects. Since no annotations are present, the description should have compensated for these gaps a bit more sharply.

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 the baseline is 3 even with no additional parameter description. The text does add a workflow note ('use its ID from suno_create_persona') but that is already present in the schema's persona_id description. It adds no semantic value beyond the structured input.

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 lead sentence names a specific verb ('Generate music'), a specific resource ('a saved artist persona'), and the benefit ('consistent vocal style'). It clearly differentiates this generation-flavored tool from the many non-generative siblings while establishing how it relates to the prerequisite suno_create_persona. Distinguishes the intended flow with confidence.

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 an explicit 'Use this when' bulleted list covering the three main use cases, plus a clear upstream instruction to create the persona first with suno_create_persona. It does not spell out when NOT to use this tool still, e.g., choosing suno_generate_music awkward or persona_vox, so some guidance left is to inference.

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