Flow Music MCP Server by useapi.net (third-party)

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

Annotations already cover the mutation/safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely new context: this kicks off a background job ('A job, usually done in under half a minute'), which tells the agent the call is asynchronous and fast rather than synchronous. It does not contradict 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?

Front-loaded with the core action and effect/parameter mapping in one dense sentence, followed by two short supporting sentences. 'POST /music/edit operation effect' is mildly cryptic technical noise, but overall there is little waste.

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 15-parameter mutation tool with no output schema, the description covers effect selection and job latency but omits how the produced clip is retrieved (e.g., via flowmusic_get_job) and what happens to errors or partially specified effects. Adequate but with clear gaps.

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 schema already labels each parameter with its effect (e.g., 'Reverb: wet mix, 0-1'). The description's grouping of parameters by effect largely repeats that mapping, adding only navigational convenience rather than new meaning, 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 ('Apply one effect to a clip') and enumerates the six supported effects with their parameter groups, so the agent immediately knows the scope. This distinguishes it from siblings like flowmusic_split_stems or flowmusic_replace_section, which operate differently on clips.

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?

'Each effect reads only its own parameters' is a concrete rule that prevents an agent from passing irrelevant fields, and the clip schema text points to where clip ids come from. However, there is no explicit when-to-use vs. alternatives guidance or statement of prerequisites (e.g., account/source-required).

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 flag destructive/idempotent/openWorld, and the description adds genuinely new behavioral context: cancellation only stops tracking, the job may still complete, and credits are consumed regardless. This is exactly the non-obvious semantics an agent must know before calling a destructive tool.

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 action and its effect, ending with the endpoint. No filler; 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 one-parameter destructive tool with rich annotations and no output schema, the description covers action, side effects, and billing consequences completely. Nothing needed 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%, so the single jobid parameter is already documented in the schema; the description adds no format or sourcing detail beyond it. Baseline 3 for a fully covered single param.

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 ('Stop tracking a running job') plus the concrete side effect of freeing a maxJobs slot. Distinct from get_job and list_jobs without needing to open 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?

Implied usage is clear (cancel a running job), but it doesn't explicitly state when to cancel versus polling get_job first, nor name alternatives. The side-effect caveat ('may still finish') is guidance about expectations rather than about tool selection.

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=false, destructive=false, idempotent=false and openWorld=true, so the safety profile is covered. The description's "A job" does add real value by signaling asynchronous execution, but it never says a job id is returned, that polling via flowmusic_get_job is required, or what happens to the source clip.

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 fragments with the purpose front-loaded and no filler. "POST /music/edit operation cover" is partly redundant with the tool name, but it is compact and the whole thing is scannable.

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 mutating, non-idempotent job tool with no output schema, the description should at least point to how the result is retrieved. It flags job semantics but leaves the return/ polling path and the fate of the input clip unexplained, so an agent has a real gap to close.

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 property descriptions are unusually rich (clip encoding, seed reproducibility, model default, strength range, instruction example), so the schema carries the parameter burden. The description adds nothing about any of the six parameters; 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?

"Restyle a whole clip in another style" names a specific verb (restyle) and resource (clip) plus the scope (whole clip), which implicitly separates it from section-level siblings like flowmusic_replace_section. It stops short of naming an explicit alternative, but the operation is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to choose cover over flowmusic_apply_effect, flowmusic_extend_song, flowmusic_remix_lyrics, or flowmusic_replace_section. "A job. POST /music/edit operation cover" is an implementation note, not usage guidance, so the agent must infer routing from the name alone.

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 it is a non-read-only, non-idempotent, open-world, non-destructive write. The description goes well beyond that by disclosing the credit cost, the ~40-150 s generation time, the ~50 s wait-then-return-jobid async pattern, and the return format (clips with public m4a/wav links). This is substantial added behavioral context, though it doesn't cover failure/retry behavior.

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 dense paragraph that front-loads what is generated, then the cost, then the async timing and result format, with no redundant or filler sentences. Every clause carries distinct 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?

For a 26-parameter, no-output-schema asynchronous tool, the description covers the aspects the structured data cannot: cost, latency, the wait-and-poll pattern with the named follow-up tool, and the shape of the returned result. Nothing an agent needs to invoke and follow up 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 baseline is 3 and per-parameter semantics are already handled. The description still adds useful cross-parameter meaning, explaining the lyrics-vs-model-written-lyrics-vs-instrumental interplay that the individual schema fields do not surface together.

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 (generate) and resource (song) via a named provider (Google Lyria / Flow Music), and enumerates the controllable dimensions (style, mood, genre, instruments, tempo, vocals) that define the input. It is readily distinguishable from siblings like flowmusic_cover_song and flowmusic_extend_song, which imply a source asset this tool does not require.

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 clear context for use: generation from a text description, with or without user lyrics, or instrumental, and explicitly notes it consumes the account's Flow Music credits. It also routes the agent to flowmusic_get_job after the wait window. It does not explicitly say when to prefer cover_song/extend_song/remix_lyrics instead, so the sibling-exclusion guidance is incomplete.

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 (readOnly=false, destructive=false, openWorld=true, idempotent=false), so the description needn't restate it. It adds genuinely non-structured context by flagging that this is an asynchronous job 'like flowmusic_create_song', implying the agent must poll for completion, plus the default extend window.

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 fragments, front-loaded with the purpose before the default and the job note. The trailing 'POST /music/edit operation extend' is an internal routing detail of marginal use to an agent, but overall it is tight and wastes little.

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 100% schema coverage and annotations present, the definition is workable, and noting the job semantics helps. However it omits how the result is retrieved (flowmusic_get_job), what happens to the source clip, and any prerequisite that the clip must come from a finished job, leaving gaps for a mutating job-launching 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 every parameter including clip, seed, model, title, extend_s, and extend_from_s is already documented in the schema. The description's '(default 150 s from its end)' merely echoes the schema defaults and adds no new syntax or format detail beyond 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?

The description gives a specific verb and resource: 'Add music to a clip, as described in instruction', which is the extend operation. It distinguishes the async-job nature by referencing create_song, but does not differentiate itself from close siblings like flowmusic_replace_section or flowmusic_cover_song.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the default behavior (150 s from the end) and that it is a job, but gives no guidance on when to choose extend over create_song, replace_section, or cover_song, nor any prerequisites such as requiring a finished-job clip. Usage is only implied at best.

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?

With annotations already declaring openWorldHint=true, idempotentHint=false and destructiveHint=false, the description adds real value beyond them: expected latency (~10-20 s) and the underlying endpoint (POST /files/generate). It does not describe auth requirements, though the schema covers the email parameter.

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 dense sentence plus a short latency/endpoint note; the action, return value, and downstream use are front-loaded 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 two-parameter tool with no output schema, the description covers the return artifact, timing, and downstream usage. Only minor gaps remain (no error/failure behavior), which is reasonable for this complexity.

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 both 'prompt' and 'email' fully. The description adds no syntax or format detail beyond what the schema states, 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 ('Generate an image from a prompt') and immediately clarifies the return artifact ('an image you can see with its asset id'), which distinguishes it from sibling generators like flowmusic_cover_song or flowmusic_create_song.

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 clear intended usage by naming where the output goes ('refImage1..10 in flowmusic_create_song') and qualifying its role ('a loose style hint'). It lacks explicit when-not-to-use guidance, but the routing context is strong enough to pick it over siblings.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds only the word 'live', hinting the read is a fresh real-time fetch rather than cached data; there is no mention of auth requirements, rate limits, or error behavior for a missing 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?

Two compact sentences with no redundancy. The purpose and returned fields are front-loaded, with the endpoint path as a trailing technical 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?

There is no output schema, and the description helpfully enumerates the return contents (plan, credits, tokens remaining), which is what an agent needs to know before calling. What remains unspecified — behavior when the email is unknown, and how this differs from flowmusic_get_usage — is minor for a simple single-resource 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 email parameter is already documented as 'The account email.' The endpoint template GET /accounts/{email} reinforces that email is the lookup key, but adds no format or validation 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 ('Read one account live from Flow Music') and enumerates the returned data (plan, credits and tokens remaining), plus the underlying GET /accounts/{email}. The singular 'one account' implicitly distinguishes it from the sibling flowmusic_list_accounts, but it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'one account' suggests this is for looking up a single known email rather than enumerating accounts or usage statistics. No explicit when-to-use, prerequisites, or routing to flowmusic_get_usage / flowmusic_list_accounts is provided.

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 and non-destructive, so the safety profile is covered. The description adds real behavioral value beyond them: it discloses what a successful response contains and what 'wait: true' actually does (~50 s block). It does not describe failure/timeout behavior or the possible status values, 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 dense sentences plus an endpoint reference, with the return contents and the wait behavior front-loaded. Slightly clipped grammar ('A song or edit job: its status...') costs a point but nothing is redundant.

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 return-value burden and does so reasonably: status, clips, ids, titles, lyrics and m4a/wav links. Missing only edge cases such as timeout behavior, error shapes, and the enumerable status values.

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 already have descriptions. The description essentially restates the 'wait' semantics from the schema ('waits up to ~50 s for it to finish') and adds nothing about the jobid format. Baseline 3 applies when the schema 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?

The description names the resource (a song or edit job) and what is returned (status, and once completed, clips with ids, titles, lyrics, and audio links), plus the endpoint GET /jobs/{jobid}. That is enough to separate it from flowmusic_list_jobs and flowmusic_cancel_job, though the phrasing is telegraphic rather than a clean verb+object sentence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: you call this to poll a job's status once you have a jobid. There is no explicit guidance on when to use it instead of flowmusic_list_jobs, no polling cadence advice, and no statement of what to do if the job has not finished after the ~50 s wait.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds the returned content (daily billing events, per-song cost) and the underlying endpoint, but says nothing about auth scope, rate limits, or time-range behavior.

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 tight sentence front-loads the resource and its contents; the trailing 'GET /accounts/usage' is mildly redundant but cheap and informative. 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 simple single-parameter read with full annotation coverage and no output schema, describing the returned fields (billing events, per-song cost) is the main thing needed and it is present. Missing only usage routing and error behavior, which are minor here.

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?

Only one parameter and schema description coverage is 100%, so the schema fully documents 'email'. The description contributes no additional semantics (e.g. whether email must be an owned account, or what happens on unknown email), 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?

Names a specific resource (account credit/token usage) and enumerates the payload contents: daily billing events and per-song cost. It is clearly distinct from flowmusic_get_account's account-detail scope, though it never explicitly names that sibling.

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?

No when-to-use statement, no prerequisites, and no routing against the closest sibling flowmusic_get_account. The agent must infer from the name alone that this is the billing/usage lookup rather than account settings.

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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds real value beyond that by disclosing the returned fields (tier, maxJobs, health) and by stressing that no upstream Flow Music call is made, which signals latency and zero side effects on the remote service.

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 terse fragments, each earning its place: what is listed, which fields come back, and the no-upstream-call fact plus the backing endpoint. Front-loaded and free of 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 usefully enumerates the key returned fields and identifies the underlying endpoint. It is nearly complete for a trivial no-arg list, missing only ordering/count expectations, which is minor for this shape of 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing about arguments the description needs to disambiguate. It could note there is no filtering/paging control, but the schema already makes the no-arg nature unambiguous.

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 Flow Music accounts') and scopes it precisely to the accounts attached to the current useapi.net API token, which separates it from job/song listing siblings. It does not explicitly distinguish itself from the singular flowmusic_get_account sibling, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage context by noting the accounts are 'stored' and that there is 'No call to Flow Music', which tells an agent this is a cheap local read. However, it never says when to prefer this over flowmusic_get_account or flowmusic_get_usage, so the alternative-routing guidance 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful scope context (only current jobs, per-account, compared against maxJobs), but says nothing about volume, pagination, or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight fragments with the scope front-loaded and no padding. The trailing 'GET /jobs' is marginal value for an agent but does expose the underlying endpoint, so it is not entirely 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 zero-param list tool with rich annotations, the description is nearly sufficient, but with no output schema present it never explains the response structure — which accounts appear, what fields each job carries, or whether results are bounded.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

The tool takes zero parameters and the schema is empty, so there are no parameter semantics to clarify; baseline 4 applies. The description's mention of per-account grouping and maxJobs does give shape to what would otherwise be an opaque call.

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 resource and scope: jobs currently running, broken down per account and measured against each account's maxJobs. The 'running now' framing distinguishes it from flowmusic_get_job (single job) and flowmusic_get_usage, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated — an agent can infer this is for checking live job status across accounts, but there is no explicit guidance on when to prefer it over get_job, list_accounts, or get_usage, and no exclusions 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior: results are ordered most recent first and each item carries ids, titles, lyrics and covers, which matters because no output schema exists. It still says nothing about rate limits or result size behavior, so it falls 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?

It is a single tight sentence with the resource and returned fields front-loaded, followed by the endpoint path. Nothing is padded, though the bare "GET /music" tag is metadata rather than agent-useful guidance and the sentence opens without an explicit verb. Efficient overall.

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 returned fields, and pagination semantics are handled by the schema (offset plus the answer's next pointer). Annotations carry the read-only/idempotent profile, so the remaining burden is light. The main gap is the absence of any account-selection or filtering guidance.

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 email, limit and offset are already fully documented in the schema, including defaults and ranges. The description adds no parameter syntax or format detail beyond the implicit account scoping, so the baseline 3 applies. The mention of most-recent-first ordering is a behavioral detail rather than a parameter hint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (clips on an account), the ordering (most recent first), and the fields returned (ids, titles, lyrics, covers), so an agent can tell it is a listing tool. It does not distinguish itself from siblings like flowmusic_list_accounts or flowmusic_list_jobs, and it calls the resource "clips" while the tool is named list_songs, a small terminology mismatch. Still clearly a read/list operation on song data.

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?

There is no statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The listing intent is only implied by the resource phrase, leaving the agent to infer that this is the general browse endpoint. No guidance on the account-scoping decision or paging workflow appears in the description.

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, destructive=false, idempotent=false, openWorld=true). The description adds genuinely useful context beyond them: that this enqueues an asynchronous job and that the original sound is preserved unless a new prompt is supplied, clarifying it is non-destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the core action front-loaded and the async nature stated immediately after. The trailing 'POST /music/edit operation remix' is terse endpoint jargon but still carries information without bloat.

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 100% schema coverage and annotations covering the safety profile, a 6-param mutation tool is mostly covered; the async-job disclosure is the key missing piece the description supplies. It does not state what the enqueued job returns (e.g., a job id for flowmusic_get_job), which is a minor residual gap given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema description coverage is 100%, so every parameter (clip id format, seed, model enum, title, lyrics tagging, prompt override) is already documented in the schema. The description mentions lyrics and the optional sound prompt but adds no format or constraint detail beyond that 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 and resource: re-sing a clip with edited lyrics, optionally overriding the sound prompt. An agent can distinguish it from flowmusic_write_lyrics and flowmusic_replace_section by the 're-sing the whole clip' framing, but no sibling is named to remove ambiguity.

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 never says when to choose this over flowmusic_write_lyrics, flowmusic_cover_song, or flowmusic_replace_section, nor what preconditions (a finished clip) are required. 'A job' hints at the async workflow but is not usage guidance.

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 flag a non-read-only, non-idempotent, open-world write. The description adds real value with 'A job.', signalling an asynchronous submission the agent must poll via flowmusic_get_job. However it never says whether the source clip is modified in place or a new result clip is produced, nor mentions cost or auth scope.

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?

It is short, front-loaded with the core action, and free of filler. The trailing fragments 'A job.' and 'POST /music/edit operation replace.' are telegraphic and only the first carries real meaning for an agent.

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 7-parameter mutation tool with no output schema and no annotations describing outcomes, the description omits the job lifecycle (polling, result retrieval), whether the original clip survives, and any permission or cost context. An agent can attempt the call but cannot predict its consequences.

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 every parameter (including seed, model, title, and the mask bounds) is already documented in the schema. The description only restates mask_start_s/mask_end_s and instruction, adding no syntax or constraint detail beyond the schema, 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?

The description states a specific verb (regenerate/replace) on a specific resource (one section of a clip bounded by mask_start_s/mask_end_s) and ties the edit to the instruction parameter. It is distinguishable from siblings such as extend_song, cover_song, and apply_effect, though it never names an alternative explicitly.

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?

There is no guidance on when to choose this over flowmusic_extend_song, flowmusic_cover_song, or flowmusic_apply_effect, and no stated prerequisites (e.g., clip must come from a finished job). Usage is only inferable from the word 'section'.

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?

Adds substantial context beyond annotations: 15-60s (up to 2 min) runtime, timeout/retry semantics, and the fact that re-running on an already-split clip returns existing stems immediately. The annotations (readOnlyHint=false, destructiveHint=false) already cover the mutation/safety profile. There is mild tension between idempotentHint=false and the described return-existing-stems behavior, but it is not a hard contradiction.

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 dense sentences, front-loaded with the action and outputs, followed by timing/retry facts. 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?

For a no-output-schema, single-param tool, the description covers what it produces (stem clips, links), how long it takes, and how to handle timeouts. Nothing an agent needs in order 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?

With a single parameter and 100% schema description coverage, the schema already explains the encoded clip id and its provenance. The description adds no parameter syntax or format detail beyond what the schema provides, so the 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 and resource: 'Separate a clip into 4 stem clips: drums, bass, vocals and other', and even names the outputs (clip ids, m4a/wav links). No sibling does stem separation, so the agent can select this unambiguously from name plus description alone.

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 clear operational context: the edit runs on a clip from a finished job/list/split, plus retry guidance ('if it times out, ask again') and the already-split shortcut. It stops short of explicit when-not-to-use or alternative routing, but no sibling performs this operation, so there is little to route away from.

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=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the endpoint and the semantics of the changed field, but it never confirms whether this replaces or merges settings, whether email must already exist, or what happens on an unknown email. Adequate but with gaps against a write tool.

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 front-loaded sentence covering the mutable field, its semantics, its range, and the API route. Slightly awkward internal phrasing ('the songs and edits it runs at once'), but no wasted sentences.

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 simple two-parameter update with no output schema and annotations covering the safety profile, the description is nearly sufficient: it identifies the single mutable field and its constraint. Missing only confirmation of whether the account must pre-exist and how exactly the update is applied.

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 both email and the maxJobs range. The description restates 'maxJobs ... (1-16)' and functional meaning ('songs and edits it runs at once'), which largely duplicates the schema without adding format or edge-case guidance. Baseline 3 per the rules.

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 ('Change an account's maxJobs') and identifies the single mutable field, so the agent knows exactly what the tool mutates. It does not explicitly distinguish itself from siblings like flowmusic_get_account or flowmusic_list_accounts, but the update semantics are unambiguous from the name plus description.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternative tools. The description names the endpoint ('POST /accounts') but never says when an agent should reach for this instead of get_account or list_accounts, leaving usage 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 (not read-only, not idempotent, not destructive, open world), and the description adds real behavioral context beyond them: format/size caps (20 MB image, 40 MB audio), the account-scoped asset id ('usable on that account only'), and the crucial semantic that references are loose hints the model does not copy. Auth mechanics and failure behavior are still unstated.

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 accepted formats and limits, then the source options and the downstream wiring, all in three dense sentences. Every clause carries information, though the trailing 'POST /files' endpoint note is minor filler and the parentheticals make it slightly heavy.

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 fills the gap by naming the return value (the asset id) and its account-scoped limitation, plus the hint-not-copy semantics. Missing only auth/permission requirements and error handling for oversized or wrong-type files.

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, but the description adds the url-vs-contentBase64 tradeoff ('small files'), the account binding of the returned id, and how the asset id maps onto refImage1..10 / refAudio1..10 slots, which the schema does not 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 (upload) and resource (image/song file as a reference), enumerates the accepted formats and size limits, and explicitly ties it to the downstream sibling flowmusic_create_song (refImage1..10 / refAudio1..10). An agent can distinguish this from the other 17 flowmusic tools 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 clear context for use: the file is a reference for flowmusic_create_song, and it distinguishes url (public https) from contentBase64 (small files). It never states when not to use the tool or what happens if the reference type doesn't match the target slot, so it stops short of explicit 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 declare a non-destructive, non-idempotent, open-world write; the description layers on genuinely useful behavior the annotations cannot convey: no audio is rendered, credit consumption is small, and latency is ~30 s. The cost and timing disclosures are the main value add.

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?

Five short sentences, densely front-loaded: what it produces, what it does not do, cost, latency, and next step. The trailing endpoint ('POST /music/lyrics') is minor 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?

For a 3-param tool with no output schema, the description covers what comes back (lyrics, title, sound prompt) and where to send it next, plus cost and latency. A brief note on output shape/formatting of the returned lyrics would close the remaining 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 the schema already documents prompt, structure and email; baseline 3 applies. The description's [Verse]/[Chorus] formatting hints lightly reinforce the 'structure' parameter but add no semantics 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: writes lyrics (with [Verse]/[Chorus] markup), a title and a sound prompt. The scope negation 'without making audio' cleanly distinguishes it from flowmusic_create_song, 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?

Tells the agent when to use it (concept-to-lyrics without audio) and gives the downstream step: 'Pass them to flowmusic_create_song.' It does not, however, address the nearby alternative flowmusic_remix_lyrics or say when to pick that instead.

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