Mureka MCP Server by useapi.net (third-party)

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true. The description adds value beyond that: the Mureka Premier plan prerequisite and the returned voice_id, plus the endpoint. It omits any note on async processing, rate limits, or how url vs contentBase64 interact when both are supplied, so it is strong but not exhaustive.

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?

A single tightly-packed sentence, front-loaded with the core action and input constraints, then alternatives and the endpoint. Every clause carries a distinct piece of information with no filler.

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 create-style tool with full schema coverage and no output schema, the description supplies what an agent needs: the input source, the plan requirement, the return value (voice_id), the natural follow-up (mureka_create_speech), and the cleanup sibling. 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?

Schema description coverage is 100%, so the schema already documents url, desc, lang, title, account and contentBase64. The description restates that title/desc/lang are required and lists the lang enum values, which duplicates rather than extends the schema. Baseline 3 is appropriate.

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+resource ('Clone a speaking voice') plus the accepted input forms (MP3 via public https url or base64) and what it returns (voice_id). It explicitly distinguishes itself from the singing-voice sibling mureka_upload_vocal, so an agent can route correctly without opening any 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 explicit when-to-use context (speaking voice from an MP3 sample, Premier plan required) and names alternatives with the selecting condition: 'For a singing voice use mureka_upload_vocal' and 'Delete a clone with mureka_delete_voice.' The alternative routing is unambiguous.

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

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

Goes well beyond the annotations: states the operation is free with no wait ('ready at once'), that the created character is publicly visible on mureka.ai by default unless private:true, how to reverse that later, and the POST endpoint. Cost, latency, and a non-obvious publishing side effect are exactly the traits annotations (readOnly/destructive/idempotent/openWorld) cannot convey.

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?

Front-loaded with the core action, then inputs, then outputs/privacy/follow-ups in tight clauses. Every sentence carries information an agent needs; nothing is padding.

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 an 8-parameter mutation tool with no output schema, the description covers inputs, the returned identifier, cost/latency, privacy side effects, and the downstream tool. An agent has everything needed to call it and act on the result.

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 100%, so the schema already carries the parameter burden (baseline 3). The description still adds useful meaning: the vocal quality precondition for vocal_id, the mutual exclusivity with song_id, and the behavioral consequence of the private flag.

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?

Specific verb+resource: 'Turn a voice into a reusable singer', with the exact inputs named (vocal_id from mureka_upload_vocal, or song_id). It is unmistakably distinct from siblings like mureka_clone_voice or mureka_upload_vocal without opening any 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?

Explicit prerequisites and routing: source must come from mureka_upload_vocal (~30 s of clear singing) or an existing song, the result feeds mureka_create_song_with_lyrics, and mureka_set_character_private / mureka_list_characters are named for follow-up. It stops short of stating when another tool (e.g. mureka_clone_voice) would be preferred, so no real exclusions.

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

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

Annotations only cover safety/idempotency, but the description adds billing cost (Mureka Gold), the mutual-exclusivity constraint on inputs, and the asynchronous result contract ('songs with song_id and mp3, or a jobid for mureka_get_job'). It even exposes the underlying endpoint. That is materially more than the annotations provide.

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?

Front-loaded with purpose and routing, then cost, then return shape, then endpoint. Mostly tight, but the fragment 'A job like mureka_create_song: songs with song_id and mp3, or a jobid for mureka_get_job' is telegraphic and slightly harder to parse than it needs to be.

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?

There is no output schema, so the description carries the return-value burden and does so by explaining the song_id/mp3 vs jobid outcomes. Combined with billing and the sibling routing, an agent has everything needed to call this correctly.

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 100%, so the baseline is 3; the description goes beyond it by stating that prompt and ref_id are mutually exclusive and by naming the tools that produce a valid ref_id (mureka_list_references, mureka_upload_reference). It does not add meaning for model/title/account, hence not a 5.

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 concrete verb and resource ('Generate two instrumentals (no vocals)') plus both input modes (prompt or reference track), and explicitly names the siblings it is NOT for (mureka_create_song, mureka_create_song_with_lyrics). An agent can distinguish it from every other generation tool without opening a 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 explicit routing rules: prompt or ref_id 'not both', and 'For songs with vocals use mureka_create_song or mureka_create_song_with_lyrics'. It also discloses the cost gate ('Costs Mureka Gold'), which is a real precondition for choosing this tool over alternatives.

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

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

Annotations cover non-readonly/non-idempotent, and the description adds cost (12 Gold per song), latency (~45-90 s), wait behavior (up to ~50 s), and dual return paths (songs inline or jobid). This is well beyond annotation content.

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: purpose, routing alternatives, async behavior and return, then endpoint. Nothing redundant, front-loaded with the action.

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-param generation tool with no output schema, it conveys cost, latency, wait cap, return shape, and the fallback job path – everything needed to call it and know what to expect.

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 100%, so parameter meaning is already in the schema. The description adds model/cost hint (V9.5: 12 per song) and confirms lyrics are auto-written from prompt, but no extra syntax or constraints beyond 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+resource: 'Generate two songs from a text description; Mureka writes the lyrics,' and explicitly distinguishes from siblings mureka_create_song_with_lyrics and mureka_create_instrumental.

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?

Explicit routing: 'For your own lyrics, a voice, a character or a reference track use mureka_create_song_with_lyrics, for no vocals mureka_create_instrumental.' Also names mureka_get_job as the continuation for the async jobid path.

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

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

Beyond the annotations (which only say non-read-only, non-destructive, open-world), the description discloses billing impact ('Costs Mureka Gold'), the async job model, and the return shapes (songs with song_id and mp3, or a jobid to poll via mureka_get_job). With no output schema, this is exactly the behavioral context the 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?

Purpose and cost are front-loaded and there is no filler, but the second sentence is telegraphic and the job/return clause ('A job like mureka_create_song: songs with song_id and mp3...') is slightly awkward to parse. Still dense with useful content per line.

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 10-parameter, no-output-schema, credit-consuming mutation, the description covers cost, alternatives, prerequisites, and result shape. It does not mention latency expectations or how long polling via mureka_get_job may take, but nothing needed 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every parameter already documents its own source tool and constraints. The description's summary of optional modifiers (voice, character, reference track, melody) largely restates the schema, adding only light relational context (motif_id works alone) that the schema also covers.

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?

'Generate two songs that sing your lyrics, styled by desc...' is a specific verb + resource + scope, and it explicitly distinguishes itself from mureka_create_song ('for a song from a description only use mureka_create_song'). It also surfaces the non-obvious detail that two songs are produced, which an agent could not infer from the name.

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 the prerequisite step (draft lyrics with mureka_write_lyrics), the alternative for text-only generation (mureka_create_song), and the exclusivity rule that motif_id 'works alone'. Routing decisions are fully specified rather than implied.

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

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

Annotations only declare the mutation/safety profile (readOnly=false, non-idempotent, non-destructive). The description adds real behavioral context beyond them: it consumes the account's speech minutes, jobs take 20-90 s, the call blocks up to ~50 s, and the return is either title/duration/mp3 or a jobid. This is exactly the extra context annotations cannot carry.

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?

Front-loaded with the core action, then constraints, alternatives, and async behavior. Dense but every clause carries information; slightly packed with the trailing 'POST /speech' detail.

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 explains the return shape (title, duration, mp3 link, or jobid), the latency envelope, and the cost model. Nothing an agent needs to invoke and interpret the call correctly 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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning by explaining the two mutually-exclusive input modes (text + voice_id, or a multi-speaker conversation array) and where voice_id comes from. It stops short of describing the optional title/account params beyond 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 (turn text into spoken audio) and immediately disambiguates from the nearest sibling with '(not singing)' and 'For songs use mureka_create_song.' An agent can distinguish this from mureka_create_song, mureka_create_song_with_lyrics, and mureka_create_video without opening a 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 explicit routing: use mureka_create_song for songs, fetch voice_id from mureka_list_voices, and fall back to mureka_get_job when a jobid is returned. The when-to-use and alternative-selection conditions are both stated.

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

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

Annotations already declare this as a non-read-only, non-idempotent, open-world write, and the description adds meaningful behavior beyond them: the video_url is returned synchronously in the same call, and unsupported model versions fail with a 400 rather than silently degrading. It does not explain that repeated calls create distinct videos, which matters given idempotentHint=false.

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, front-loaded with the effect and return value, followed by eligibility and the endpoint. The trailing 'POST /music/video-generate' is the least useful element for an agent but costs almost nothing.

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?

No output schema exists, so the description correctly fills that gap by naming the returned video_url and confirming synchronous return. Combined with the model-version failure rule, an agent has what it needs to invoke correctly, with only minor gaps around retry/idempotency behavior.

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?

There is only one parameter (song_id) and the schema covers it at 100% with its format and account-scoping note, so the schema carries the semantic load. The description adds no extra parameter meaning beyond what the schema states, making the baseline 3 appropriate.

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 artifact: 'Make a lyrics video (mp4) for one song and return its video_url'. The resource (video output for an existing song) is clearly distinguished from siblings like mureka_create_song, mureka_create_instrumental, and mureka_extract_stems.

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 a concrete eligibility rule: works for songs on V9, V8, O2, V7.6, V7.5-all and edited songs, while a V9.5 song returns 400. That is real when-it-works/when-it-fails guidance, though it never names an alternative tool or workflow for handling the unsupported case.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the bar is lower; the description still adds real value by disclosing the cascade behavior (songs are preserved) and the permanence ('Cannot be undone'), neither of which is derivable from the annotations. It stops short of permission requirements or error/failure behavior, keeping it from a 5.

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 compact clauses, front-loaded with the destructive permanence, followed by the retention caveat and then the alternative. No filler, and the human-readable text is correctly labelled with the underlying DELETE /music/characters endpoint.

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 destructive singe-target delete with no output schema, the description covers irreversibility, side effects on dependent resources, and the nearest alternative — everything needed to call it safely. It does not indicate what the call returns on success, a minor gap in an otherwise complete definition.

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 100% with both parameters documented in the schema (account, character_id), so the schema carries the burden and baseline 3 applies. The description adds nothing about parameter format or the multi-account case beyond what the schema already says.

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 ('Permanently delete') and resource ('one of your characters'), and immediately scopes the blast radius with 'songs already made with it are kept' — an agent can tell exactly what this does and does not affect. It also names the sibling it is not (mureka_set_character_private), which is strong differentiation in a long sibling list.

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 explicit routing: use this to delete, use mureka_set_character_private to merely hide it. The condition that selects each tool is stated outright, and the irreversibility warning tells the agent when extra caution is warranted.

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

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

Annotations already carry destructiveHint=true and idempotentHint=true, so the safety profile is known; the description still adds value by stating 'Cannot be undone' and clarifying the exact artifact scope versus vocals. The endpoint (DELETE /files) is a useful extra detail that the annotations don't convey.

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: action, irreversibility, alternative tool, plus endpoint. Nothing is redundant and the destructive warning is front-loaded.

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?

No output schema is needed for a delete, and the description covers scope, irreversibility, identifier provenance, and the confusable sibling operation. An agent has everything required to invoke it correctly.

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 100% with both params documented, so the baseline is 3. The description goes beyond that by identifying the 'id' parameter as the ref_id sourced from mureka_list_files, giving the agent provenance for the value it must supply.

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 ('Permanently delete a reference track you uploaded') and pins the identifier semantics with 'its ref_id from mureka_list_files'. It cleanly separates this from mureka_delete_vocal and mureka_delete_voice by naming which artifact is affected.

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?

Tells the agent the operation is irreversible and routes the singing-voice case to mureka_delete_vocal, which is genuine sibling differentiation. It stops short of spelling out prerequisites (e.g., what happens if the ref is in use by a song), so it's strong but not exhaustive.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds meaningful context beyond those flags: the deletion is permanent, cannot be undone, and runs against the song's Mureka account.

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?

The description is three tightly packed sentences: the core action and permanence warning come first, followed by routing alternatives and the underlying endpoint. Every sentence earns its place with no redundancy.

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 single-parameter delete tool with rich annotations and full schema coverage, the description covers permanence, reversibility, account scope, and sibling alternatives. No output schema exists, so return values need not be explained.

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 100%, and the sole song_id parameter is fully documented in the schema including its expected format and source. The description adds no extra syntax or meaning beyond the schema, so the baseline of 3 is appropriate.

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 ('Permanently delete one song') and scopes it to the Mureka account. It explicitly distinguishes this tool from adjacent delete tools (mureka_delete_character, mureka_delete_file, mureka_delete_vocal), so an agent can select it without opening schemas.

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 description clearly indicates when to use this tool (to delete a song) and routes some non-song deletions to alternative tools. It does not cover every sibling delete tool (e.g., mureka_delete_speech, mureka_delete_voice), but the primary routing guidance is explicit and useful.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally. The description adds the irreversibility emphasis ('Cannot be undone') and the underlying endpoint (DELETE /speech), which sharpens an agent's caution beyond the boolean hints.

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, no filler, and the destructive scope is front-loaded ahead of the sibling routing hint. Every clause 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 single-resource delete with 100% schema coverage, no output schema needed, and annotations carrying the safety hints, the description covers everything an agent needs: permanence, id source, and the sibling to use instead.

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 100%, so both parameters are already documented. The description only adds provenance for 'id' (from mureka_list_speech); it says nothing about the optional 'account' parameter, so it does not exceed the baseline for a fully documented 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 ('delete') and resource ('speech item'), plus the scope qualifier 'one'. It explicitly differentiates from the sibling mureka_delete_voice, so an agent can route 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?

Names the alternative for a related resource (cloned voices → mureka_delete_voice) and tells the agent where the required id comes from (mureka_list_speech). It gives clear context but no broader exclusions such as what to do about files or characters.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds genuinely new behavior: the deletion is permanent and cannot be undone, but characters built from the voice keep working. That side-effect detail is not encoded in any annotation.

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 compact sentences. The destructive constraint is front-loaded ('Permanently delete'), followed by the consequence and the sibling routing. No filler.

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 two-parameter destructive delete with full schema coverage and annotations carrying the safety profile, the description covers what to pass, where the id comes from, what happens to dependent characters, and which sibling to use. Return values are not explained, but no output schema exists and a DELETE needs little description of its response.

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 100%, so both parameters are already documented. The description explains where the id value comes from (vocal_id from mureka_list_vocals with mine: true), which adds sourcing guidance but no format or type detail beyond the schema. Baseline 3 is appropriate.

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: 'Permanently delete a singing voice you uploaded'. It explicitly distinguishes this tool from mureka_delete_voice (which handles cloned speech voices), so an agent can tell the two delete tools apart 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?

It tells the agent the precondition (a voice you uploaded, with vocal_id from mureka_list_vocals filtered to mine: true) and names the alternative tool for cloned speech voices. When-to-use and when-not-to-use are both explicit.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, covering the safety profile. The description adds context beyond annotations: it's permanent, irreversible, and explicitly notes which related entity (singing voices) is handled elsewhere. Does not describe auth requirements or rate limits, keeping it at a 4.

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 action and scope, followed by the irreversibility warning and the sibling alternative. No wasted words.

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?

Complete enough for a destructive deletion tool with annotations covering safety. It covers irreversibility, provenance, and sibling routing. Missing only minor details like auth prerequisites, but those are less critical given the annotation signals.

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 100%, so the schema already documents both parameters (account and voice_id). The description references 'voice_id from mureka_list_voices with cloned: true', adding provenance guidance, but doesn't add format or syntax beyond the schema. Baseline 3 is appropriate.

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 (delete) and resource (a cloned speech voice), scoped to cloned voices only via 'voice_id from mureka_list_voices with cloned: true'. Distinguishes itself from mureka_delete_vocal by naming that sibling for singing voices.

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?

Explains when to use it (cloned speech voices) and names the alternative for a related case (mureka_delete_vocal for uploaded singing voices). The 'Cannot be undone' warning makes the irreversible nature explicit.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description adds real value instead by disclosing the Premier-plan gating on the stem type and the underlying POST /music/download endpoint. It omits link expiry or rate-limit behavior, which keeps it short of a 5.

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 sentences, zero waste: the primary action and its plan constraint come first, the sibling routing second. Nothing is padding.

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?

Covers purpose, plan gating, and sibling routing for a two-enum read tool. With no output schema present, it does not describe what the returned link looks like or whether it expires, which is a minor but real gap for a download tool.

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 100% and both parameters are fully documented there, including the enum meanings and the song_id format, so the baseline is 3. The description's restatement of the two type values adds little beyond what the schema already spells out.

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 (get a download link) and resource (basic stems package or license certificate) plus the enum values that select between them. It explicitly distinguishes itself from the sibling pair mureka_extract_stems/mureka_download_stems, so an agent can route without opening schemas.

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?

Explicitly names the alternative path ('For the full split into up to 12 stems with MIDI and DAW sessions use mureka_extract_stems, then mureka_download_stems') and states the prerequisite for the stem type (Mureka's Premier plan). Both the when-to-use and when-to-use-something-else conditions are given.

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

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

Annotations cover the safety profile (readOnly/idempotent/non-destructive), and the description adds real behavioral context beyond them: the three output modes keyed off stem_name/daw/neither (wav+MIDI vs DAW session vs ZIPs), the Premier plan prerequisite, and the absence of credit cost. This is what an agent needs to predict the result.

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 dense sentence, front-loaded with the action and the prerequisite, then the per-parameter outcomes. Slightly run-on, but every clause carries information the agent needs.

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 must characterize the return values, and it does so precisely (download links, and what files each mode returns). Plan and cost constraints are also covered, leaving no material gap.

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 100%, so baseline is 3, but the description adds meaning the schema does not: each stem_name yields that stem's WAV and MIDI, each daw value yields one session file, and supplying neither yields ZIPs of all audio and all MIDI. That clarifies the effect of each parameter rather than restating it.

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 ('Get download links from a finished extraction') and anchors it to the sibling that produces its input ('stems_id from mureka_extract_stems'). An agent can distinguish this from mureka_download_song and mureka_extract_stems immediately.

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?

Explicitly says the id must come from mureka_extract_stems and that extraction requires Mureka's Premier plan, plus a credit note ('Free: no new extraction and no Gold'). It does not contrast with mureka_download_song, but the context and prerequisites are clear.

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

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

Goes well beyond the annotations (which only declare non-read-only, non-idempotent, open-world, non-destructive): it discloses the return shape ('one complete song with only that stretch replaced, on the source song's model'), a hard cost/plan gate ('needs a paid Mureka plan, 20 Gold'), and the asynchronous job contract ('the song or a jobid for mureka_get_job'). These are exactly the behavioral traits an agent must know before calling.

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?

Dense and front-loaded: the core operation leads, then constraints, then sibling routing, then the endpoint. Every clause earns its place, though the telegraphic fragments ('A job: the song or a jobid for mureka_get_job. POST /music/edit.') are terse enough to slightly hurt readability.

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 6-parameter mutation tool with no output schema, the description supplies the missing pieces: cost, plan requirement, what is and is not replaced, the return artefact, and the async job handoff. Nothing an agent needs to invoke it correctly is absent.

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 100%, so start_milliseconds, end_milliseconds, keep_melody, lyrics and song_id are already fully documented in the schema. The description reinforces the time-range framing and the keep_melody default but adds no syntax, units or edge-case meaning beyond what the schema provides. Baseline 3 applies when the schema carries the load.

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 precise verb+resource+scope: 'Re-sing one time range of a song (start_milliseconds to end_milliseconds) with new lyrics and keep the rest.' It also names the sibling operations it supersedes for adjacent tasks, so an agent can distinguish it from mureka_extend_song and mureka_remix_song without opening any 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?

Explicitly routes two near-siblings: 'To add to the end use mureka_extend_song, to restyle the whole song mureka_remix_song.' The when/when-not conditions are stated inline, and the async-job follow-up (mureka_get_job) is named, leaving nothing to inference.

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

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

Annotations already cover the safety profile (readOnly=false, idempotent=false, openWorld=true, destructive=false). The description adds genuinely useful behavior beyond that: it reveals the async job pattern ('A job: songs with song_id and mp3, or a jobid for mureka_get_job') and the POST /music/extend endpoint. It does not spell out auth or rate-limit behavior, keeping it just short of a 5.

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?

Front-loaded with the core action and tightly worded with zero filler, but the final telegraphic sentence ('A job: songs with song_id and mp3, or a jobid for mureka_get_job') is slightly clipped and reads awkwardly.

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 states the return shape (lengthened songs carrying song_id and mp3, or a jobid) and the async follow-up path. Combined with explicit sibling routing and schema-documented params, an agent has what it needs to call the tool correctly; only auth/retry details are absent.

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 100% and both parameters are documented in the schema, including the song_id format and the account-scoping behavior. The description adds nothing about parameter syntax or constraints beyond what the schema already provides, so the baseline 3 applies.

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 with scope: 'Continue an existing song from its end with new lyrics, returning the lengthened songs.' It also names the sibling tools that handle different tasks (mureka_edit_section, mureka_remix_song), so the agent can separate this tool from its neighbors without reading any 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?

Explicit routing rules are given: use mureka_edit_section to change one part, use mureka_remix_song to re-record in a new style. This is clear when/when-not guidance with named alternatives, not merely implied context.

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

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

Annotations declare it is not read-only and not idempotent; the description confirms and enriches this with concrete costs (100 vs 20 Gold), the entitlement requirement (Premier plan), re-charge on repeat calls, and the returned artifacts (wav/mp3 per stem, BPM, stems_id or jobid). That is precisely the added context beyond annotations.

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?

The core operation is front-loaded ('Split a song into stems') and every clause carries needed information (plan, pricing, reuse, output). It is very dense and relies on stacked parentheticals, which slightly hurts readability but not substance.

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 mutation-style extraction with no output schema, it covers the entitlement gate, cost tradeoff, reuse path, expected job duration/outputs, and follow-up tool for the async jobid. Nothing an agent needs to call it correctly 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?

Schema coverage is 100% and both parameters are documented there, including the default and prices for all_stems, so the description largely restates schema content. It adds a little cost framing but no new syntax or format detail beyond the schema baseline.

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+resource ('split a song into stems') with the scope of each mode. It names the sibling tools it is not (mureka_download_stems for reuse, mureka_download_song for the basic package), so an agent can distinguish it from related stem/download tools.

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?

Explicitly states when to use it, the plan prerequisite (Mureka Premier), and names alternatives with the conditions that select them (reuse stems_id vs. basic package via mureka_download_song). The 'every call is a new extraction and is charged again' warning tells the agent when NOT to call it.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so credit goes to the added context: 'no call to Mureka' tells the agent this reads cached useapi.net state rather than fetching live data, which matters for freshness. It still does not mention staleness timing or pagination/size limits, so not a full 5.

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 clauses: what it reads, why to use it (with alternatives), and the underlying route. Scope is front-loaded and there is no filler.

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?

There is no output schema, and the description compensates by naming the returned fields (sign-in mode, token expiry, sign-in error). Combined with the sibling routing and the cached-data caveat, an agent has everything needed to call it correctly.

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 100% with a single parameter whose meaning and provenance ('from mureka_list_accounts') are fully documented. The description only implies the account selector via the 'GET /accounts/{account}' route and adds no format or syntax detail, so baseline 3 is appropriate.

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?

Names a specific verb and resource ('Read one Mureka account as useapi.net stores it') and enumerates exactly what it returns: sign-in mode, session token expiry, and sign-in error. It explicitly distinguishes itself from mureka_list_accounts and mureka_get_profile, so an agent can select it without opening the schemas.

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 trigger ('Use it to see why an account fails') and names two alternatives with their distinct scopes — mureka_list_accounts for every account, mureka_get_profile for live plan and Gold. This is a clean when-to-use plus when-to-use-something-else.

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

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

Annotations already cover read-only/idempotent/non-destructive, yet the description adds substantial context: the wait timeout (~50 s), the 7-day retention window, retry-while-running semantics, and the exact result shapes per job type plus failure reasons. This is well beyond what the annotations provide.

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?

Front-loaded with the core purpose, then layered detail, ending with the HTTP route. Dense but every clause (result shapes, retention, retry, sibling routing) carries load.

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 carries the full burden and delivers: it describes return contents per job type, failure output, retention, and waiting behavior. Nothing an agent needs to call and interpret it correctly 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining wait's retry consequence ('call again while it is still running') and clarifying that jobid comes from a song/edit/remix/stems/speech 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?

States a specific verb (read/get) and resource (one job), and enumerates the job types it covers (song, edit, remix, stems, speech). It also names the sibling mureka_list_jobs and contrasts scope ('shows what is running now'), so an agent can distinguish it 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 explicit routing to the sibling mureka_list_jobs for listing current jobs, plus operational guidance on the wait flag and retry ('call again while it is still running'). Strong contextual guidance, though it doesn't explicitly state when not to use it or its relation to mureka_get_song.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint. The description adds real behavioral context beyond them: the data is fetched

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 resource, then the decision rule, then the disambiguation, then the endpoint. No filler.

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?

No output schema exists, and the description compensates by naming the returned fields (plan name, end date, Gold balance). For a one-optional-param read tool with full annotation coverage, that is nearly complete; only failure modes (missing account, auth) are unstated.

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 100% and the single `account` parameter is documented in the schema, including its optionality and provenance (mureka_list_accounts). The description adds no syntax or format detail beyond that. Baseline 3 is appropriate when the schema already does the work.

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 (

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?

Explicitly prescribes when to call it (

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

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

Annotations cover the flag profile (readOnly=false, idempotent=false, openWorld=true), and the description adds cost (10 Gold), latency (~5-30 s), and a nuanced caching rule (re-sending the same YouTube link returns the earlier zip uncharged). It also names the endpoint. This is real behavioral context beyond the 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?

Front-loads the core action and outputs, then sources, then cost/latency/endpoint. Four tight sentences, no filler, 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?

Despite no output schema, the description explains the return value (zip containing MusicXML, staff PDF, numbered-notation PDF), the source options, the cost model and latency, so an agent has everything needed to invoke and interpret the call.

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 100%, so the schema already documents all four parameters. The description nonetheless clarifies what url may be (YouTube or mureka static-cos upload URL) and what song_id refers to, adding meaning in the selection between them beyond raw schema text.

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 (transcribe) and resource (melody, chords, lyrics into sheet music) plus the concrete outputs (MusicXML, staff PDF, numbered-notation PDF). No sibling tool does anything similar, so it is trivially distinguishable from the rest of the mureka_* set.

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?

Enumerates the three valid source kinds (own song via song_id, YouTube link, or an MP3 already uploaded via mureka_upload_reference/mureka_upload_vocal) and thus routes the agent to the required prerequisites. It does not explicitly state when to prefer one source over another, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuine context by enumerating the returned fields and the underlying GET route, though it doesn't discuss account scoping or auth beyond what the schema states.

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, front-loaded with the verb and returned fields, then usage, then the alternative, then the route. The trailing 'GET /music/{song_id}' is slightly redundant but harmless.

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 enumerates the response fields, so an agent knows what a read returns. Combined with annotations covering the safety profile and a fully documented parameter, the definition is complete for a single-ID read.

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 100%, and the single song_id parameter is fully documented in the schema (including its format and that it runs on that song's account). The description adds no parameter detail beyond the schema, so the baseline of 3 applies.

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 ('Read one song') and enumerates exactly what is returned (title, duration, model, lyrics, style prompt, instrumental flag, mp3 link). It explicitly distinguishes itself from the sibling mureka_list_songs, which lists every song on an account.

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?

Provides clear when-to-use context ('before an edit, extend or remix to see what the song sings') and names the contrasting alternative mureka_list_songs for bulk listing. It stops short of a fully explicit when-not statement, but the routing is unambiguous.

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

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

Annotations declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower, yet the description still adds real context: the audio is persisted into Mureka storage, the response shape is named, and an approximate latency/duration (~5-15 s) is disclosed. It does not mention auth requirements or whether imported files persist/expire, keeping it short of a 5.

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?

Four tight sentences, front-loaded with the core action, then the return payload, then the next-step routing. The trailing 'GET /files/youtube' is a compact implementation hint rather than filler.

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?

There is no output schema, yet the description names the returned fields and their use, and it links to the three tools that consume the result plus the sheet-music alternative. Nothing an agent needs to call this correctly 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?

Schema description coverage is 100% and both parameters (url, account) are already documented in the schema. The description repeats the 'YouTube link' notion but adds no format details, accepted URL variants, or the account-selection behavior beyond what the schema states, so baseline 3 applies.

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+resource ('Fetch the audio of a YouTube link into Mureka storage') and enumerates the return payload (title, duration, mp3 url). It is clearly distinguishable from siblings like mureka_get_sheet_music and mureka_upload_* which it explicitly names.

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?

Explicitly routes the agent downstream: 'Pass that mp3 url as url to mureka_upload_reference, mureka_upload_vocal or mureka_upload_motif.' It also names the alternative path for sheet music ('mureka_get_sheet_music takes the YouTube link directly'), so when-to-use and when-not-to-use are both covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld. Beyond that, the description adds genuine behavioral context: 'no call to Mureka' signals this is a local metadata lookup against the useapi.net token, not a live upstream fetch, and it discloses the failure surface (session health 'or the sign-in error'). It stops short of describing pagination or ordering.

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 compact sentences, front-loaded with the purpose and return contents, then the routing guidance, then the HTTP endpoint. Every clause carries information — no filler or restatement of the title.

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 compensates by naming the returned fields (account id, sign-in mode, session health / sign-in error) and by flagging that the account id is the key other tools consume. Nothing needed to select or call this zero-param read 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 the baseline is 4 and there is nothing for the description to disambiguate. It correctly adds no parameter discussion, keeping focus on the account-id discovery role.

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 every Mureka account added to this useapi.net API token') and immediately enumerates the returned fields (account id, sign-in mode, session health / sign-in error). It also names the two closest siblings it must be distinguished from (mureka_get_account, mureka_get_profile), so an agent can tell it apart without opening any 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?

'Start here to find the account id other tools take' is an explicit routing instruction, and the alternative tools are named with the exact condition that selects them (session expiry → mureka_get_account; plan and Gold → mureka_get_profile). Both when-to-use and when-to-use-something-else are covered.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is low; the description still adds ordering (newest first), the returned field set, the pagination mechanism, and the underlying endpoint GET /music/characters. It does not mention rate limits or result-size caps, so 4 rather than 5.

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?

Dense but efficient: the core list behavior and returned fields come first, then sibling routing, then pagination. Every clause carries information, though the packed sentence listing three sibling tools is slightly heavy for a single line.

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 compensates by naming the returned fields and ordering plus the pagination contract, which is what an agent needs to call and consume this tool. The optional account parameter and any handling of an empty list remain unaddressed, keeping it below a 5.

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 100%, so both parameters (account, last_id) are already documented, making 3 the baseline. The description reinforces last_id's pagination role but adds no syntax or format detail beyond the schema, and never mentions the optional account parameter.

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 your characters (reusable singers)'), clarifies the domain-specific term with a gloss, and enumerates the returned fields and ordering ('newest first: name, tags, private or published...'). It is clearly distinguishable from siblings like mureka_list_voices or mureka_list_songs.

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?

Routes the agent to the adjacent operations explicitly: create via mureka_create_character, change visibility via mureka_set_character_private, and use the returned character_id with mureka_create_song_with_lyrics. It also explains how to paginate ('Pass last_id for the next page'). No explicit when-not-to-use or exclusion, 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.

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so safety is covered. The description adds value beyond that: it discloses pagination behavior ('Pass last_id for the next page'), the HTTP surface (GET /files), and the shape of each returned record, which matters since there is no output schema.

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?

Front-loaded with the core purpose, then disambiguation, then pagination, then the endpoint. Sentences are dense and mostly earn their place; the trailing 'GET /files' is mild redundancy but harmless and low-cost.

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, enumerating returned fields is valuable, and pagination plus account context are covered. A hint about when pagination terminates or what an empty result means would round it out, but nothing critical 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?

Schema description coverage is 100%, so both account and last_id are already documented. The description restates last_id's pagination role but adds no format, default, or edge-case detail (e.g., how to tell when the last page is reached) beyond 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+resource (list the reference tracks you uploaded) and enumerates the returned fields (title, duration, url, ref_id). It explicitly disambiguates from the two nearest siblings by naming them: Mureka's own library is mureka_list_references, uploaded voices are mureka_list_vocals with mine: true.

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?

Explicitly routes the agent: use this for tracks uploaded via mureka_upload_reference, use mureka_list_references for Mureka's own library, use mureka_list_vocals (mine: true) for uploaded voices. Alternatives and the condition selecting each are stated outright, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond that: results span every account tied to the token, only in-flight jobs appear, and each row carries verb/elapsed time plus a total. It does not discuss pagination or ordering, which keeps it short of a 5.

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 compact sentences, zero filler, front-loaded with what is listed before the routing hint. Every clause carries information: scope, fields, exclusion, alternative, endpoint.

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 input parameters and no output schema, the description carries the full burden and does so: it names the fields returned, the filtering rule, and where to go for per-job detail. An agent has everything needed to call it and interpret the result.

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; the baseline for a 0-param tool applies. The description instead clarifies the implicit scoping (the token's accounts), which is the only input-like dimension that matters here.

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 jobs running now') with explicit scope ('on each account of this API token') and enumerates the fields returned (verb, elapsed time, total). It also carves itself away from mureka_get_job, so an agent can distinguish it from the sibling that fetches a single job.

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 both the inclusion condition ('jobs running now') and the exclusion ('finished jobs are not listed'), plus an explicit alternative with the selecting condition: use mureka_get_job with its jobid for one job's status and result. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value beyond that by naming the returned fields (title, genre, mood, url, ref_id) and the pagination mechanism, plus the underlying endpoint. It stops short of stating page size or rate limits, so not a 5.

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?

Four compact sentences, no filler, with the resource and scope front-loaded and each remaining sentence carrying a distinct routing or return-value fact.

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 compensates by enumerating the returned fields and the pagination cursor; with annotations covering safety, the only remaining gap is page size, which is minor for a list tool.

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 100%, so baseline would be 3, but the description adds real meaning the schema lacks: mood/genre are tags sourced from mureka_list_styles, and last_id is specifically the previous page's cursor. This cross-tool semantics is what the flat schema strings cannot convey.

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 Mureka's library of 30-second reference tracks') with scope and optional filters. It also explicitly distinguishes itself from mureka_list_files ('Your own uploads are listed by mureka_list_files') and mureka_list_styles, so an agent can tell the three apart without opening any 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 explicit routing: use tags from mureka_list_styles to filter, use the returned ref_id in mureka_create_song_with_lyrics or mureka_create_instrumental, use mureka_list_files for own uploads, and pass last_id for the next page. When-to-use and when-to-use-something-else are both covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds useful behavioral context beyond that: ordering (newest first), pagination model (one page at a time, pass last_id), and what fields are returned. It does not describe page size or rate limits, keeping it below a 5.

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?

Dense but front-loaded: purpose first, then returned fields, then pagination instruction, then sibling routing, then the endpoint. No filler.

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?

No output schema, yet the description lists the returned fields (song_id, title, duration, model, mp3 link), covers pagination, and routes to alternatives. Complete for a simple list tool.

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 100%, so baseline is 3. The description adds value on last_id by explaining the pagination loop ('Pass last_id from the answer for the next page'), slightly exceeding the schema-only baseline.

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 ('list the songs'), notes the scope (one account, newest first, paginated), and names sibling tools it differs from (mureka_get_song for lyrics/style, mureka_list_jobs for running jobs). An agent can select it without opening the 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?

Explicit routing: 'For one song's lyrics and style use mureka_get_song, for jobs still running mureka_list_jobs.' This gives a concrete when-to-use-this-vs-alternatives signal.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds genuine behavioral context on top: pagination via last_id, the shape of the returned record, and the underlying GET /speech endpoint.

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: purpose and payload first, then pagination, then the two related tools. No filler and nothing buried.

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?

There is no output schema, but the description compensates by listing the returned fields, and it covers pagination and the sibling relationships. An agent has everything needed to call this correctly.

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 100%, so both parameters are already documented. The description's 'Pass last_id for the next page' restates the schema rather than adding format or edge-case detail, so the baseline 3 applies.

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 gives a specific verb and resource ('List the speech audio made on an account') and enumerates what comes back (title, duration, id, mp3 link), which is enough to separate it from mureka_list_songs, mureka_list_voices and the other list_* siblings.

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 routes the agent explicitly to mureka_delete_speech for removal and mureka_list_voices for the voice source, and explains that last_id advances the page. There is no explicit 'when not to use' statement, 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.

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so 'Read-only' is redundant restatement. The genuinely additive bits are 'all at once' (implies an unpaginated full dump, useful for caching decisions) and the endpoint reference. It says nothing about the shape or size of the returned tag collection.

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, then the reuse recipe, then the safety/endpoint note. Every clause carries information an agent would otherwise have to guess.

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 one-optional-param read tool with rich annotations, the description covers what it returns conceptually ('the genre and mood tags ... all at once') and how to consume it. The only gap is that no output schema exists and the description does not say whether tags come back as flat strings or grouped by genre vs mood.

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 100% and there is a single optional 'account' parameter whose description already explains the mureka_list_accounts source and the single-account fallback. The tool description adds no further meaning, so the baseline 3 applies.

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 genre and mood tags Mureka understands') and scopes it with 'all at once', which separates it from the parameterized list tools like mureka_list_references or mureka_list_songs. An agent can identify it immediately without opening the 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?

Goes well beyond 'when to use': it names the exact downstream slots — the desc field of mureka_create_song_with_lyrics and mureka_remix_song, the mood/genre of mureka_upload_reference, and filtering in mureka_list_references. This is a discovery-then-reuse workflow made explicit, with no alternatives left to infer.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: the fields returned (title, duration, sample url, vocal_id), the pagination mechanism, and the underlying GET /music/vocals endpoint.

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?

Front-loads the core purpose and packs routing, pagination, and return info into a compact block. It is dense and parenthetical, but nearly every clause carries load, so little 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 paginated read with no output schema, the description supplies the return fields, pagination approach, account/mine semantics, sibling routing, and the endpoint. Nothing essential to correct invocation 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?

Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by framing mine as 'the voices you uploaded' and by tying vocal_id to downstream tools (create_song_with_lyrics, create_character), adding usage meaning the schema does not.

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 singing voices) and immediately differentiates from the sibling mureka_list_voices, which it names as handling speech voices. An agent can distinguish it from clone_voice, upload_vocal, and list_voices without opening any 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?

Explains the mine:true condition (uploaded voices) versus the default library, names the alternative mureka_list_voices for speech voices, and notes pagination via last_id. It stops short of an explicit 'when not to use' for other listing scenarios, but the routing context is clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description usefully adds that cloned voices originate from mureka_clone_voice and that last_id drives pagination, but does not add further operational context such as rate limits or result ordering.

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?

Dense but front-loaded: the core action and scope come first, then mode semantics, then pagination, then the sibling exclusion. No sentence is filler.

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 compensates by enumerating returned fields (title, language, description, voice_id) and the pagination contract. It also names the endpoint, so an agent has everything needed to call and consume the result.

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 100%, so baseline is 3. The description reinforces the cloned true/default-false distinction and the last_id paging pattern, but adds little syntax or format detail beyond what the schema already states.

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 speech voices') and immediately disambiguates scope: speech voices for mureka_create_speech versus singing voices handled by mureka_list_vocals. An agent can distinguish it from every list_* sibling without opening a 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?

The description names the alternative explicitly (mureka_list_vocals for singing voices) and gives the conditional that switches mode ('with cloned: true the ones you cloned with mureka_clone_voice'). It also ties the output to its downstream consumer, mureka_create_speech.

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

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

Annotations declare non-read-only, non-idempotent, non-destructive, open-world. The description adds what carries over (lyrics unless replaced), what the output is (two songs for same Gold), and that a jobid routes to mureka_get_job. It doesn't state rate limits or what happens to the original song, but adds substantial behavioral context beyond annotations.

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?

Four sentences, each earning its place: core action, carryover/scope, alternative routing, and output/job routing. Front-loaded with the main purpose.

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 6-param creation tool with full schema coverage and annotations, this is nearly complete: it explains output shape and routing. Missing only edge cases like what happens to existing song or failure modes, but nothing critical for correct 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?

Schema coverage is 100%, so parameters are fully documented. The description adds some implications (lyrics apply only with vocals, desc default is original style), but baseline 3 applies when schema already does the heavy lifting.

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 ('Re-record a whole song') with clear scope (whole song, vocals or instrumental) and names the sibling mureka_edit_section for partial changes. An agent can distinguish it from all other mureka_* creation tools.

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?

Explicitly says to use mureka_edit_section when changing only one part, and clarifies that for instrumental-only desc, title and model apply. This is clear when/when-not guidance with a named alternative.

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

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

Annotations declare idempotent and non-destructive; the description adds that the character is unchanged and keeps working in songs, plus the endpoint. It discloses the state transition effect beyond what annotations convey, though it doesn't mention auth/permission 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?

Two front-loaded sentences plus a routing pointer and endpoint; every clause earns its place with no padding.

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?

Adequate for a simple toggle with no output schema; it states the return (id and new state) and the effect on existing usage. Minor omission of error/permission behavior keeps it from a 5.

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 100%, so the schema already documents all three parameters. The description reinforces the private flag semantics but adds little beyond the schema excerpt.

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 (hide/publish) and resource (character), and crisply defines both boolean states. It distinguishes itself from the sibling delete tool by name.

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?

Explicitly defines the true/false semantics and names the alternative operation (mureka_delete_character) for a different intent, so an agent knows when to use this versus deletion.

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

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

Annotations already declare write (readOnlyHint=false), non-idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavior: the return value (motif_id), the privacy guarantee ('Not visible to other Mureka users'), and the endpoint (POST /files/motif). It stops short of noting auth/rate-limit or duplicate-upload behavior, so not a 5.

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 tight paragraph: purpose first, then the sibling alternatives, then the privacy note and endpoint. Every clause carries routing or behavioral information; nothing is padding.

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 correctly supplies the return value (motif_id) and its downstream consumer, plus the privacy characteristic. The mutual exclusivity of url vs contentBase64 is left entirely to the schema, which is acceptable at 100% coverage, but a note on which to prefer would have closed the last gap.

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 100%, so url, account and contentBase64 are already fully documented, including the url-vs-base64 alternative and the 2048-char limit. The description restates the url/base64 choice but adds no syntax or format detail beyond the schema; baseline 3 applies.

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 ('Upload an MP3 melody idea') and immediately names the sibling upload tools it must not be confused with (mureka_upload_reference for style, mureka_upload_vocal for voice). An agent can distinguish it from every other upload tool without opening a 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 explicit routing rules: use this for a melody motif, use mureka_upload_reference for a style reference, mureka_upload_vocal for a singing voice. It also states the downstream condition ('return its motif_id for mureka_create_song_with_lyrics, where motif_id works alone'), so the agent knows both when to call it and what it feeds.

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

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

Annotations cover write/openWorld/non-idempotent/not-destructive, yet the description adds real behavioral value beyond them: the privacy consequence ('visible to all Mureka users'), the terminal endpoint (POST /files), and the downstream consumption path via ref_id into mureka_create_song_with_lyrics and mureka_create_instrumental.

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?

Dense but front-loaded: upload action first, constraints and cross-references after. The long parenthetical and chained clauses make it slightly crowded to scan, though nearly every clause carries usable 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, the description compensates by naming the return values (ref_id and file url), and it covers visibility, source options, tag sourcing, and follow-up tools. An agent has everything needed to invoke this correctly and use the result.

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 100%, so the schema carries the baseline. The description still adds meaning the schema lacks: that title/mood/genre are mandatory, that valid mood/genre values should be sourced from mureka_list_styles, and that the audio gets trimmed to ~30 s. It says nothing about the optional youtube or account parameters, but those are self-documented.

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+resource ('Upload an MP3 as a reference track') and immediately scopes the accepted sources (public https url or base64). The 'reference track' framing distinguishes it from siblings like mureka_upload_motif, mureka_upload_vocal, and mureka_import_youtube.

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 operating context (Mureka consumes ~30 s, so trim first; tags come from mureka_list_styles) and routes lifecycle actions to siblings (mureka_list_files for listing, mureka_delete_file for deletion). It does not, however, explain when to choose a reference track over mureka_upload_motif or mureka_upload_vocal, leaving that comparison to inference.

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

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

Annotations cover the safety profile (readOnly=false, openWorld=true, destructive=false, idempotent=false), and the description adds genuine behavior: input format and constraint (~30 s clear vocals, public https or base64), the return fields (vocal_id, duration, url), and the raw endpoint. It stops short of stating whether repeated uploads create duplicate vocal_ids, but otherwise adds real context beyond the annotations.

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 plus an endpoint token — input spec first, then routing via vocal_id, then the disambiguating alternative. No filler; every clause 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?

No output schema exists, yet the description names the return fields (vocal_id, duration, url), so an agent knows what it gets back and how to consume it. Combined with input constraints and sibling routing, the definition is complete for this upload tool.

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 100%, so both url and contentBase64 are already documented, including that base64 is 'instead of url; small files'. The description only adds the ~30 s clear-vocals guidance, which is useful but marginal against the fully-documented schema; baseline 3 is appropriate.

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+resource ('Upload an MP3 of a singing voice') and its scope (~30 s of clear vocals), and names the sibling it is not ('For a speaking voice use mureka_clone_voice'). An agent can immediately distinguish it from mureka_upload_reference, mureka_upload_motif, and mureka_clone_voice.

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?

Explicit down-stream routing: 'Use the vocal_id in mureka_create_song_with_lyrics, or make a reusable singer with mureka_create_character', plus a named alternative for speaking voices (mureka_clone_voice). Both when-to-use and when-to-use-something-else are covered.

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

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

Annotations declare it is not read-only and not idempotent. The description adds that it is free, responds in seconds, and returns text rather than audio – useful operational context. It does not discuss failure modes or rate limits, but it does more than repeat annotations.

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 compact sentences plus a routing sentence and endpoint. The key constraint ('without making audio') and output ('returns the lyrics text') are front-loaded. 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 2-param, no-output-schema tool, the description covers purpose, cost/latency, output type, and next-step routing. An agent has everything needed to invoke it correctly. Only minor gaps like error behavior remain.

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 100%, so baseline is 3. The description clarifies the core input ('from an idea' corresponds to the prompt) and the non-audio output, adding a little meaning beyond the schema. It does not explain the account parameter, but the schema already documents it fully.

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+resource ('Write song lyrics'), distinguishes from audio-making siblings with 'without making audio', and names the exact output ('returns the lyrics text'). An agent can tell this apart from mureka_create_song and mureka_create_song_with_lyrics immediately.

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?

Explicitly says what to do next: pass the result to mureka_create_song_with_lyrics, mureka_extend_song, or mureka_edit_section. It also clarifies the boundary ('without making audio'), which routes the agent away from audio-creation tools.

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