HanoLab converts uploaded speech or singing with your saved voices. Connect with OAuth, upload audio privately, get credit quotes and retrieve voice-conversion results. Requires a HanoLab Starter, Creator or Pro account and credits. Official publisher: HanoLab (hanolab-ai). Docs: https://hanolab.com/docs/mcp. Public connection metadata, skills and CLI client: https://github.com/hanolab-ai/hanolab-integrations.
Scored across 9 tools
Each tool targets a distinct resource or action within a clear workflow (upload → list audio → list voices → prepare → convert → get_task). The only mild overlap is prepare_voice_conversion vs convert_voice and list_conversions vs get_task, but descriptions clearly separate quoting from spending and listing from refreshing status.
All nine tools follow a consistent snake_case verb_noun pattern (convert_voice, get_credits, list_audio, prepare_voice_conversion, etc.). No mixed conventions or vague standalone verbs.
Nine tools is well-scoped for a voice conversion workflow, with each tool earning its place across account, upload, catalog, quoting, submission, and task-tracking stages.
The surface covers the full lifecycle: identify account, check credits, upload, list owned audio/voices, prepare a quote, convert, and poll task status. A cancel/abort operation for in-flight conversions is the only notable gap, a minor limitation agents can work around.
Spend HanoLab credits to submit the prepared conversion ONLY after the user confirms its cost and budget. Reuse the exact quote_id after interruption: repeated calls return the original task without another debit. A failed task needs a separate user decision before a new quote.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | ||
| confirmed | Yes | ||
| max_credits | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, and the description adds behavior well beyond that: the call debits HanoLab credits, repeated calls with the same quote_id are idempotent and return the original task without a second debit, and a failed task blocks resubmission until the user makes a new decision. These are exactly the cost and retry semantics an agent needs.
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 dense sentences, front-loaded with the credit-spend precondition, each carrying distinct operational rules with no filler. It is slightly packed — the idempotency and failure rules are compressed — but 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 3-required-parameter mutation with no output schema, the description covers the critical unknowns: credit debiting, user confirmation gating, idempotent retry, and failure handling, and it incidentally reveals that a task is returned. Only the return payload shape and credit-ceiling behavior are left unspecified, which is acceptable given there is no output schema.
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 0%, so the description must carry parameter meaning. It gives real semantics for quote_id (must be reused exactly after interruption) and for max_credits/confirmed via the requirement that the user confirm cost and budget before submitting. It doesn't explain the 1-1000 max_credits bound or the uuid format, but the intent of each parameter is clear from prose.
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 names a specific action (submit the prepared conversion) and the resource (voice conversion), and it implicitly distinguishes itself from the sibling prepare_voice_conversion by requiring an existing quote_id and referring to 'the prepared conversion'. It stops short of naming the prepare tool explicitly, so an agent must infer the two-step relationship, but the purpose is unambiguous.
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 states explicit preconditions ('ONLY after the user confirms its cost and budget'), an idempotency rule for retries ('Reuse the exact quote_id after interruption'), and a recovery path for failures ('A failed task needs a separate user decision before a new quote'). When-to-use, when-not-to-retry, and the alternative action after failure are all spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a private one-hour browser upload link. Ask the user to open it, choose an audio file or MP4 and return here. Requires the same HanoLab account; no credits are spent. This tool cannot read local paths or ChatGPT attachments directly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only say not-read-only, not-destructive, closed-world) by disclosing link lifetime (one hour), privacy, the account requirement ('same HanoLab account'), cost behavior ('no credits are spent'), and a hard input limitation that would otherwise cause a failed call. This is exactly the behavioral context an agent cannot infer from structured fields.
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 tight sentences with no filler: purpose first, then the user interaction step, then the account/cost/limitation constraints. Every sentence carries information the agent needs to act.
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?
With no output schema, the description still covers the creation semantics, expiry, requirements, and constraints, and 'upload link' implies the return value. It could be slightly more explicit about what the call returns (URL only vs. a link plus handle) and whether the link expires even if unused, but nothing essential 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly frames all required information as user-side actions rather than arguments.
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 a specific verb and resource ('Create a private one-hour browser upload link') with the key qualifiers (private, one-hour) front-loaded, so the agent immediately knows what artifact this produces and how long it lasts.
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 the intended workflow ('Ask the user to open it, choose an audio file or MP4 and return here') plus an explicit limitation ('cannot read local paths or ChatGPT attachments directly'), which tells the agent when this tool is the right path. It does not name a sibling alternative or an exclusion case, so it falls 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.
Read the connected account’s plan and available credits. Does not purchase credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds value by confirming the read-only scope in plain language ("Does not purchase credits"), guarding against an agent treating this as a billing action.
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, action stated first and the negative boundary second. Nothing is padded and no sentence is wasted.
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 trivial zero-param read with full annotation coverage, the description says enough to call it correctly and sketches what comes back (plan, available credits). Return shape is not detailed, but no output schema exists and the payload is self-evident.
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 tool takes zero parameters and the schema has no properties, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.
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 names a specific verb (read) and resource (the connected account's plan and available credits), so an agent knows exactly what this returns. It does not need to distinguish from siblings, which are all voice/conversion tools, but it also makes no attempt at routing context.
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?
"Does not purchase credits" is a useful when-not boundary, but it names no alternative tool and gives no positive condition for calling this versus checking plan elsewhere. Usage is only implied by the word 'Read'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the HanoLab account connected to these tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds the scoping context that the result is the account tied to the current tool session, but nothing about auth requirements or call frequency.
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?
One sentence, front-loaded with the verb and the target, with no filler. Every word 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?
An output schema exists, so return-value details need not be in the description, and the zero-parameter surface keeps the tool simple. The description is complete enough to invoke correctly, though it could note that no arguments are required.
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 tool takes zero parameters, which is the baseline-4 case, and the description correctly implies nothing needs to be supplied. There is no parameter semantics for it to clarify or obscure.
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 a specific verb ('Identify') and resource ('the HanoLab account connected to these tools'), which is unambiguous about what the tool returns. It doesn't reference or differentiate from any sibling, but the sibling list is entirely audio/voice operations, so the resource alone distinguishes it.
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?
Usage is only implied: an agent can infer you call this to learn which account is authenticated, but the description states no explicit when-to-use condition, prerequisites, or alternative. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an owned task and return completed audio links. Refreshes worker status and may persist completion or a failure refund. Poll about every 10 seconds; do not submit a new paid task while waiting.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark it as non-read-only; the description goes further and explains the side effects (refreshes worker status, may persist completion or issue a failure refund), which justifies readOnlyHint=false. It still does not say what is returned while the task is still pending or what happens if the task is not owned.
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 short sentences with zero filler: purpose first, side effects second, operational constraint last. Every clause carries actionable information.
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?
With no output schema and a mutating tool, the description covers return content, side effects, and polling cadence, which is most of what an agent needs. It omits what a non-terminal task response looks like and how ownership failures surface.
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 0%, so the description must compensate for the single task_id parameter. 'An owned task' does imply the identifier must reference a task the caller owns, but no format, sourcing, or invalid-id behavior is described (the uuid format is carried 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?
States a specific verb and resource ('Check an owned task') plus the payoff ('return completed audio links'), which distinguishes it from list_conversions and the preparation tools. It never names a sibling explicitly, so the boundary with list_conversions is inferred rather than stated.
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 concrete operational guidance: poll roughly every 10 seconds and do not submit a new paid task while waiting. That tells the agent how to use it in a polling loop, but there is no explicit statement of when this tool is the wrong choice versus list_conversions or get_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent audio uploaded through this connection. Use the exact audio_id, never a local path or an arbitrary URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, closed-world), so the bar is lower. The description adds that results are limited to recent uploads tied to this connection and that returned IDs must be used verbatim, but says nothing about result count, ordering, or pagination.
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 tight sentences with zero filler; the purpose is front-loaded and the id-usage caveat follows immediately after.
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, no-output-schema list tool, the description covers what is returned (recent uploads via this connection) and how to use the key field (audio_id). The only omission is any indication of how many results or how they are ordered.
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 tool takes zero parameters, so the baseline is 4. The description's mention of 'recent' hints at the implicit ordering/window, but there is nothing more to document.
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 a specific verb and resource ('List recent audio uploaded through this connection'), with scoping qualifiers ('recent', 'uploaded through this connection') that distinguish it from the conversion/voice siblings. It does not name a sibling tool explicitly, so it stops short of full differentiation.
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 warning to use the exact audio_id rather than a local path or arbitrary URL is genuinely useful downstream guidance, but it addresses how to consume the result, not when to choose this tool over list_conversions, list_voices, or convert_voice. 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.
Find recent conversions submitted with this connection. Use get_task to refresh a task. This does not start new tasks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, non-destructive, non-open-world behavior, so the bar is lower. The description still adds useful context: results are scoped to conversions submitted with this connection, and the tool does not start new tasks.
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 short sentences, front-loaded with the core purpose. Every sentence adds routing or scope information with no wasted wording.
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 listing tool with annotations covering safety, the description is nearly complete. Minor gaps remain around recency definition and pagination or result limits, but none are critical for basic invocation.
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 tool has zero parameters, so there are no parameter semantics to document beyond the baseline. A 4 is appropriate because there is nothing the description could add for invocation inputs.
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 states a specific verb and resource: finding recent conversions submitted with this connection. It also distinguishes the tool from siblings by naming get_task for refreshes and explicitly saying it does not start new tasks.
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 names an alternative tool (get_task) for the refresh case and states the exclusion that this tool does not start new tasks. This gives an agent clear routing guidance between listing existing conversions and initiating or refreshing work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the connected user’s own saved voices and whether they are ready. If none are ready, open voicelab to create one.
| 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, so the safety profile is covered. The description adds that each voice carries a readiness state, which is useful behavioral context, but says nothing about pagination, ordering, or empty-result handling beyond the voicelab hint.
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, front-loaded with the primary action. The second sentence is functional rather than filler, though the 'open voicelab' reference assumes context the agent may not have.
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 no-parameter, read-only list tool with no output schema, the description covers what is returned (saved voices and readiness). Mentioning what fields each voice includes would help, but the essentials for correct invocation are present.
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 tool takes zero parameters, so the baseline is 4. There is no parameter semantics to explain and no schema gap to compensate for.
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 a specific verb and resource ('list the connected user's own saved voices') plus the returned attribute ('whether they are ready'). It does not explicitly distinguish itself from siblings like list_audio or list_conversions, so it falls short of a 5.
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?
Offers a conditional next step ('If none are ready, open voicelab to create one'), which implies intent to check availability before creating a voice. There is no explicit when-to-use-vs-alternatives guidance or mention of sibling tools, so usage remains implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare a fixed quote for uploaded audio and a ready owned voice. No credits are spent. Explain estimated_credits, obtain the user’s budget and explicit confirmation, then use convert_voice with this exact quote_id.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_id | Yes | ||
| voice_id | Yes | ||
| full_song | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false/destructiveHint=false/openWorldHint=false, so the description carries the real behavioral weight: it discloses that no credits are spent, that it produces a fixed quote_id that must be reused verbatim, and that a human confirmation step is required. It does not say whether the quote expires or for how long it stays valid.
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 short sentences with no filler; the no-cost guarantee and the confirmation requirement are front-loaded ahead of the handoff instruction.
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?
With no output schema, the description usefully names the return value (estimated_credits) and the artifact to carry forward (quote_id), which is what an agent needs to complete the two-step flow. Minor gaps remain around quote validity and the undocumented full_song parameter.
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 0%, so the description must compensate, and the input schema itself has no parameter descriptions. The description implies prerequisites for audio_id ('uploaded audio') and voice_id ('ready owned voice'), adding real constraint meaning, but says nothing about the full_song flag or UUID formats, leaving one of three parameters unexplained.
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 a specific verb (prepare) and resource (a fixed quote for uploaded audio plus an owned voice), and names the sibling it hands off to (convert_voice). An agent can distinguish this from convert_voice without opening either schema.
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 an explicit ordered workflow: explain estimated_credits, obtain the user's budget and explicit confirmation, then call convert_voice with this exact quote_id. This is when-to-use, when-not-to-act, and the alternative all in one.
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.
convert_voicecreate_upload_linkget_creditsget_profileget_tasklist_audiolist_conversionslist_voicesprepare_voice_conversionAI stem splitter and vocal remover. Split songs from public audio links into vocals and instrumental, a 4-stem Basic Split (vocals, drums, bass, other) or 6 stems with guitar and piano, one song or a batch of up to 10. Each split returns MP3 stem links and a link to practise the song in StemConsole's practice room, with WAV links and a ZIP of all stems on Pro. Account tools show the plan and splits left, list, rename and delete songs, and list and create setlists. Connect with OAuth at https://stemconsole.ai/mcp/account, or use an API key at https://stemconsole.ai/mcp. Free accounts get 5 splits a month.
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
Compose, edit and render video with your AI agent. Turn footage into finished edits with content-aware reframing, word-timed captions and motion graphics. Hosted MCP with OAuth sign-in; cloud processing uses credits.
Generate full songs with vocals, instrumentals and sound effects from text. One server for Suno, Google Lyria, Mureka, MiniMax, ACE-Step, YuE and ElevenLabs. Your agent can quote the credit cost before generating, start a song, wait for it to finish and return download links. Sign in with OAuth; optional daily credit caps; retries never charge twice.
Add one secure layer between your agents and this server.
