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.