Royalty-free music for apps, games, video and podcasts: generate a track from a prompt, a genre or an image, swap individual instruments, run an endless stream, or search a ready-made catalogue.
Scored across 21 tools
Most tools target clearly distinct resources and actions, and descriptions explicitly draw the boundaries (e.g. generate_track vs generate_track_instant vs regenerate_similar, edit_track vs regenerate_similar). The main residual overlap is within the generation cluster, where an agent must read carefully to pick the right one, but the guidance is strong enough to prevent most misselection.
Every tool follows a consistent snake_case verb_noun pattern (create_checkout_link, delete_customer, edit_track, generate_track, get_capabilities, list_customers, set_stream_intensity, start_stream). No camelCase or vague verb-only names appear anywhere in the set.
21 tools is on the heavier side, but the server legitimately spans several domains (track generation/editing, streaming control, library search, billing, and customer provisioning), so most tools earn their place. It is slightly above the comfortable range but not gratuitous.
The surface covers generation, iterative editing, variations, streaming control, library search, billing, and customer lifecycle well. Minor gaps exist: there is no explicit stop_stream or stream-status tool (only start/restart/set_*), and no track-deletion operation, though these are workaroundable or covered indirectly.
Create a Stripe Checkout link for a plan.
Returns a URL. It does not charge anyone — the user has to open it and enter payment details themselves. Show them the plan, its price and what it changes before handing the link over.
Creating a link for an email that already has a company attaches the subscription to that existing company.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Billing email. The company is found or created from it. | ||
| coupon_id | No | ||
| company_name | No | ||
| redirect_url | No | Where Stripe sends the user after paying. | |
| stripe_price_id | Yes | From list_plans. | |
| redirect_url_cancel | No |
| Name | Required | Description |
|---|---|---|
| next_step | Yes | |
| session_id | No | |
| checkout_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses the key behaviors an agent would otherwise get wrong: the call itself moves no money, a URL is returned for the user to complete payment, and passing an email tied to an existing company attaches the subscription to that company. That last detail is a real side-effect disclosure no annotation covers.
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 verb, resource and return value in the first two lines, and each following sentence carries information (no-charge, existing-company attachment). Slightly instruction-flavored ('Show them the plan...'), which is useful but reads more like prompt text than tool documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description needn't explain the response shape, and it covers the critical non-obvious semantics (no immediate charge, existing-company linkage). Remaining gaps are the undocumented optional parameters (coupon_id, company_name, redirect_url_cancel) and failure/expiry behavior for the generated link.
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 50%, and the description only reinforces what the schema already says for email ('company is found or created from it') and stripe_price_id ('from list_plans'). coupon_id, company_name and redirect_url_cancel get no added meaning anywhere, so the description does not compensate for the coverage gap.
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: 'Create a Stripe Checkout link for a plan', plus the concrete return ('Returns a URL'). It is distinguishable from siblings like open_billing_portal, provision_customer and list_plans — this is the link-generation step, and the description makes that role obvious 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 real usage context: it does not charge anyone, the user must open the link and pay, and the agent should present the plan, price and change set first. It does not name the adjacent alternatives (open_billing_portal, provision_customer) or state exclusions, 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.
Delete a customer and free its seat.
Irreversible, and it revokes that user's access token immediately — any stream they are listening to stops. Confirm with the user before calling it, and never call it on the customer this server provisioned for itself.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | Mubert customer id, not your custom_id. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| note | Yes | |
| customer_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds important behavioral context beyond those hints: irreversibility, immediate access-token revocation, and stopped listening streams. It also identifies the privileged customer that must be excluded, which is not captured in 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 description is front-loaded with the core action and then layers consequences and safety constraints. Every sentence earns its place: deletion, seat freeing, token revocation, stream impact, confirmation, and the server-provisioned exclusion. There is no redundant or filler text.
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?
The tool has rich annotations, a complete input schema, and an output schema, so the description does not need to explain return values. It covers the critical behavioral details an agent needs: irreversibility, token revocation, stream stopping, confirmation, and the self-provisioned customer exclusion. This is complete for a destructive single-parameter 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%, and the schema itself clarifies that customer_id is a Mubert customer id, not a custom_id. The description does not add any further parameter meaning or formatting details. Baseline 3 is appropriate because the schema already carries the parameter documentation.
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: delete a customer and free its seat. It also distinguishes the action from siblings like list_customers and provision_customer by making the destructive consequence explicit. An agent can understand the tool's core purpose 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?
It gives explicit when-to-use guidance via confirmation, and a clear when-not-to-use exclusion: never call it on the server-provisioned customer. These are concrete operational constraints that go beyond generic advice. No alternative delete tool exists among the siblings, so the guidance is complete for this tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-roll or remove parts of an existing track — "swap the bass", "drop the vocals", "give me a different lead".
This is the tool for refining a track step by step. Three things govern how to use it in a chain:
Each edit makes a NEW track. The original is never modified. Pass the id returned by the previous edit into the next one; reusing the original id silently discards everything done so far and still answers success.
Each edit costs a full track off the quota. A five-step session
is five tracks. Check get_capabilities before starting a long one.
Replacement is best-effort. If the underlying collection has no alternative for a part at this tempo and key, replacing it removes it instead — a success response with the instrument simply gone. Offer the result for a listen rather than asserting the change landed.
One part at a time is the right granularity: it keeps each step
reviewable and avoids spending a track on a combination the user did not
ask for. mode cannot be changed by editing — regenerate for that.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | ||
| bitrate | No | ||
| duration | No | ||
| track_id | Yes | The track to edit. In a chain of edits this is the id returned by the PREVIOUS edit, not the original — each edit makes a new track. | |
| intensity | No | ||
| delete_stems | No | ||
| wait_seconds | No | ||
| replace_stems | No | Whole sections to re-roll: DRUMS (drums, percs, hats, claps), BASS, LEADS (mids, leads, pads), VOCALS, FX (fx, riser, impact). Coarser than replace_instruments — use it when the user names a section rather than one part. | |
| delete_instruments | No | ||
| replace_instruments | No | Single parts to re-roll: DRUMS, PERCS, HATS, CLAPS, BASS, MIDS, LEADS, FX, VOCALS, PADS, RISER, IMPACT. Map what the user says onto these — a melody, lead line, riff or 'that horn/synth' is LEADS; a pad, string or chord bed is PADS; a countermelody or stab sitting under the lead is MIDS; a sweep into a drop is RISER; a hit on the drop is IMPACT. |
| Name | Required | Description |
|---|---|---|
| bpm | No | |
| key | No | |
| url | No | Download link once done. |
| mode | No | |
| format | No | |
| prompt | No | |
| status | Yes | done, failed or pending. |
| bitrate | No | |
| duration | No | |
| track_id | No | |
| important | No | |
| expires_at | No | After this the audio is deleted and the URL stops working. |
| session_id | No | |
| edited_from | No | The track this one was derived from. Edits and variations never modify the original — they mint a new track, and this is the link back. |
| playlist_index | No | |
| how_it_was_served | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: each call produces a NEW track and never mutates the original, each call burns a full track of quota, and replacement is best-effort so a 'success' can silently drop a part. This is exactly the non-obvious, chain-affecting context annotations cannot express; no contradiction with destructiveHint=false since the source track is preserved.
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 purpose followed by three numbered constraints — dense and well-structured, with no filler. It does run long for a tool description, but nearly every sentence carries actionable guidance.
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?
Output schema exists so return shape needn't be covered, and the description correctly calls out the misleading success semantics. Remaining gap is the undocumented output/encoding params (format, bitrate, duration) and wait_seconds behavior, which an agent must infer.
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?
Coverage is only 30% across 10 params. The description reinforces track_id chaining and part-level granularity (mapping 'bass'/'vocals' to stems), but says nothing about format, bitrate, duration, intensity, delete_* variants, or wait_seconds, leaving most params to the bare 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 ('Re-roll or remove parts of an existing track') and grounds it in user-level examples ('swap the bass', 'drop the vocals'). It also distinguishes itself from the sibling regenerate_similar/regenerate path with 'mode cannot be changed by editing — regenerate for that.'
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 chaining rules (pass the previous edit's id), a recommended granularity ('one part at a time'), a quota caution pointing at get_capabilities, and a clear exclusion for mode changes. An agent knows when to use this and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a royalty-free track from a prompt, a playlist, or an image.
Provide exactly one of prompt, playlist_index, or an image. Call
get_capabilities first — the allowed bitrates, formats, modes and the
maximum duration are per-license, and this consumes quota.
A brief that says what NOT to have ("no drums", "nothing percussive",
"no vocals") is exclude_stems / exclude_instruments, and "straight
into the drop" is start_from_part — both are honoured by the
generator itself, so prefer them over generating and editing afterwards.
This waits for the render and returns a downloadable URL. Prefer
playlist_index with one of the instant durations when the brief allows
it: that path can return in a single round trip instead of rendering.
The audio expires — download it as soon as this returns.
| Name | Required | Description | Default |
|---|---|---|---|
| bpm | No | Only valid with playlist_index. | |
| key | No | Musical key, e.g. 'C' or 'Am'. Only with playlist_index. | |
| mode | No | track (default), loop for seamless looping, jingle or mix — the last two only with playlist_index. | |
| format | No | mp3 or wav, if the license allows. | |
| prompt | No | Text description of the music, in English. Needs the 'ttm' feature. Cannot be combined with bpm or key. | |
| bitrate | No | ||
| duration | Yes | Length in seconds, at least 5. Durations of 5, 6, 8, 10, 15, 20, 30, 40, 60, 180, 240, 300 can be served instantly from the pre-rendered store when generating from a playlist_index without bpm/key; any other value always costs a full render. The upper bound is per-license — see get_capabilities. | |
| image_url | No | Public http(s) URL of an image to score. Needs the 'itm' feature. PNG/JPEG/WEBP/BMP, between 50 KB and 10 MB. | |
| intensity | No | ||
| image_base64 | No | Image bytes as base64, as an alternative to image_url. | |
| wait_seconds | No | How long to wait before handing back a track id. | |
| exclude_stems | No | Stems the track is generated WITHOUT, the negative brief: DRUMS (drums, percs, hats, claps), BASS, LEADS (mids, leads, pads), VOCALS, FX. 'No drums' is this, not an edit afterwards - the track is built without them from the first bar. Only with playlist_index. | |
| playlist_index | No | Channel from list_playlists, e.g. '6.4.0'. Cheapest and fastest option — only this input can be served from the instant store, and only it accepts bpm and key. | |
| start_from_part | No | Open the track on this part instead of its intro: DROP ('straight into the drop', 'no intro', 'skip the build-up'), BREAK or MAIN. Only with playlist_index; loops and jingles have no intro to skip. | |
| exclude_instruments | No | Single parts to leave out: DRUMS, PERCS, HATS, CLAPS, BASS, MIDS, LEADS, FX, VOCALS, PADS, RISER, IMPACT. Finer than exclude_stems - 'no hi-hats' is HATS, 'no vocals' is VOCALS. Only with playlist_index. |
| Name | Required | Description |
|---|---|---|
| bpm | No | |
| key | No | |
| url | No | Download link once done. |
| mode | No | |
| format | No | |
| prompt | No | |
| status | Yes | done, failed or pending. |
| bitrate | No | |
| duration | No | |
| track_id | No | |
| important | No | |
| expires_at | No | After this the audio is deleted and the URL stops working. |
| session_id | No | |
| edited_from | No | The track this one was derived from. Edits and variations never modify the original — they mint a new track, and this is the link back. |
| playlist_index | No | |
| how_it_was_served | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/destructive/idempotent/open-world flags; the description adds substantive behavior: it consumes quota, it blocks while rendering and returns a downloadable URL, and the audio expires so it must be downloaded promptly. It also discloses the exclusive-input constraint, which annotations do not convey. Slight gap: it does not say what happens when the wait times out (that a bare track id comes back instead of a URL), which is the one behavior an agent most 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?
Front-loaded with the one-line purpose, then tight paragraphs each carrying a distinct operational rule. Slightly sprawling at five paragraphs, but every sentence adds either a constraint or a routing heuristic rather than restating the schema.
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, quota-consuming, generative tool with per-license limits and an output schema, this covers constraints, prerequisite (get_capabilities), input exclusivity and artifact expiry. Return-value details are legitimately left to the output schema. Only the wait_seconds timeout behavior is left unexplained.
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 already 87%, so the baseline is 3, but the description adds genuine conceptual mapping: negative briefs ('no drums', 'nothing percussive') map to exclude_stems/exclude_instruments and 'straight into the drop' maps to start_from_part. That is exactly the translation help an agent needs to pick the right field from natural-language input.
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 a royalty-free track') plus the three distinct input modalities (prompt, playlist, image). This clearly separates it from siblings like edit_track, regenerate_similar and generate_track_instant, which do different things with different inputs.
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 real routing rules: exactly one of prompt/playlist_index/image, call get_capabilities first for per-license limits, and prefer the playlist_index + instant-duration path when the brief allows. Also advises preferring exclude_stems/start_from_part over generate-then-edit. It never names generate_track_instant or wait_for_track as alternatives, so the sibling-level routing is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a pre-rendered track from the store, or fail fast.
Use this when predictable latency matters more than exact parameters — a live demo, an interactive UI. It never falls back to rendering, so it either returns a finished track in one round trip or tells you nothing matched.
Still consumes quota. generate_track tries the store first anyway and
falls back to rendering; reach for this one only when waiting is worse
than failing.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| format | No | ||
| bitrate | No | ||
| duration | Yes | Must be one of: 5, 6, 8, 10, 15, 20, 30, 40, 60, 180, 240, 300. | |
| intensity | No | ||
| playlist_index | Yes | Channel from list_playlists. |
| Name | Required | Description |
|---|---|---|
| bpm | No | |
| key | No | |
| url | No | Download link once done. |
| mode | No | |
| format | No | |
| prompt | No | |
| status | Yes | done, failed or pending. |
| bitrate | No | |
| duration | No | |
| track_id | No | |
| important | No | |
| expires_at | No | After this the audio is deleted and the URL stops working. |
| session_id | No | |
| edited_from | No | The track this one was derived from. Edits and variations never modify the original — they mint a new track, and this is the link back. |
| playlist_index | No | |
| how_it_was_served | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give generic hints (readOnlyHint=false, idempotentHint=false, openWorldHint=true). The description adds the crucial traits they don't convey: no fallback to rendering, an all-or-nothing single round trip, and that quota is still consumed — matching the non-read-only annotation without contradicting it.
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 single-line purpose, then two tight paragraphs covering the trade-off and the quota caveat. No sentence is wasted and the alternative is named before the reader has to infer anything.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and the description fully covers failure semantics, cost, and tool selection. The remaining gap is the four undocumented optional parameters, which is a genuine but bounded omission.
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 only 33%: duration and playlist_index are documented in the schema, but mode, format, bitrate, and intensity are undocumented in both places. The description adds no parameter meaning whatsoever, so it fails to compensate for the coverage gap.
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 ('take a pre-rendered track from the store') and immediately contrasts it with the sibling generate_track. An agent can distinguish the two 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?
Explicit when-to-use ('predictable latency matters more than exact parameters — a live demo, an interactive UI') plus the explicit when-not ('reach for this one only when waiting is worse than failing') and the named alternative generate_track with its differing fallback behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this Mubert license allows and how much quota is left.
CALL THIS FIRST, before generating anything. It returns the only authoritative answer to "which bitrate/format/mode/intensity may I ask for", "how long may a track be", and "how many tracks are left today".
Guessing these instead costs a wasted call and a 403. The notes field
carries behaviours you cannot infer from the API: when tracks expire,
which durations can be served instantly, and whether this license is a
trial (which silently changes what the library returns).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| notes | Yes | Behaviours that cannot be inferred from the API surface. |
| quota | Yes | |
| allowed | Yes | |
| license | Yes | |
| per_request | Yes | |
| defaults_when_omitted | Yes | What the API substitutes for a parameter you omit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds substantive context they cannot: the notes field carries expiry, instant-serve durations, and trial status that 'silently changes what the library returns,' plus the 403 consequence of guessing.
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 statement and the CALL THIS FIRST imperative, then supporting detail. Slightly verbose with the quoted question list, but 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?
Output schema exists, so return values needn't be enumerated, yet the description still adds value by flagging the notes field's hidden behaviors. Nothing an agent needs to invoke 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?
Zero parameters, so per the rubric the baseline is 4. The description has no parameters to explain and adds no misleading parameter semantics.
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 — license capabilities and remaining quota — with a clear read verb implied by the title. An agent immediately understands this is the entitlement/quota lookup, distinct from the generate_* and 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?
Explicitly says 'CALL THIS FIRST, before generating anything,' giving both sequencing and the trigger condition. It also names the concrete decisions it resolves (bitrate/format/mode/intensity, max duration, remaining tracks) and warns that guessing causes a wasted call and a 403.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover which filter values the pre-made library actually has.
Returns each filter with its available values and a track count. Pass
filters you have already chosen to see what remains compatible — e.g.
genres="electronic" narrows the bpm values to those that exist for
electronic tracks.
Use this before search_library rather than guessing value names; the library rejects nothing and simply returns an empty list for a value that does not exist, which is indistinguishable from "no results".
| Name | Required | Description | Default |
|---|---|---|---|
| moods | No | ||
| genres | No | ||
| themes | No | ||
| activities | No |
| Name | Required | Description |
|---|---|---|
| filters | Yes | Each filter with its available values and track counts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds meaningful non-obvious behavior: the library rejects nothing and returns an empty list for a non-existent value, which is indistinguishable from 'no results'. That is real value beyond the annotations, though it doesn't cover error modes or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: what it returns, how to use filters, why to use it first. Front-loaded with the core purpose and no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not needed, and the description supplies the discovery workflow and the empty-list gotcha an agent needs. Complete for a zero-required-parameter read 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 0%, so the description must carry the load, and it does explain the cross-filter semantics with a concrete example (genres="electronic" narrows compatible values). It does not define the individual dimensions (moods/themes/activities) or note they are single strings, and it references 'bpm' which is not actually a 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 ('Discover which filter values the pre-made library actually has') and clarifies the return shape (each filter with available values and a track count). It is clearly distinguishable from siblings like search_library.
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 'Use this before search_library rather than guessing value names', naming both the alternative tool and the reason. It also explains the narrowing workflow when passing already-chosen filters. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one track: its status, parameters, download URL and expiry.
| Name | Required | Description | Default |
|---|---|---|---|
| track_id | Yes | Track id, or a session id. | |
| by_session_id | No | Set when passing a session id. |
| Name | Required | Description |
|---|---|---|
| bpm | No | |
| key | No | |
| url | No | Download link once done. |
| mode | No | |
| format | No | |
| prompt | No | |
| status | Yes | done, failed or pending. |
| bitrate | No | |
| duration | No | |
| track_id | No | |
| important | No | |
| expires_at | No | After this the audio is deleted and the URL stops working. |
| session_id | No | |
| edited_from | No | The track this one was derived from. Edits and variations never modify the original — they mint a new track, and this is the link back. |
| playlist_index | No | |
| how_it_was_served | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered without the description. The description's added content (status, parameters, download URL, expiry) largely restates what the output schema already documents, so it contributes little 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?
A single efficient sentence that leads with the action and resource, then enumerates returns. Every clause is short and no filler is present, though the returns enumeration partly duplicates the output schema.
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 an output schema and annotations present, the definition can stay lean, and it does. But for a tool sharing a crowded namespace with list_tracks, wait_for_track and search_library, the absence of any routing or timing guidance leaves a real 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 critical nuance — that track_id accepts either a track id or a session id, and by_session_id must be set in the latter case — is fully documented in the schema. The description adds nothing about parameters, which is the baseline 3 for full schema coverage.
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 (Fetch) and resource (one track) plus the payload contents, so the agent knows it retrieves a single track object. It does not, however, differentiate itself from siblings like list_tracks, wait_for_track, or search_library.
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 by 'one track' — the single-item counterpart to list_tracks. There is no guidance on when to use this versus wait_for_track (which likely polls until ready) or search_library, and no mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the customers provisioned under this license.
Check here before provisioning a new one — seats are limited, and
customers created by this server are prefixed mcp_.
Access tokens are deliberately omitted: listing them would dump every end user's credentials into the transcript. Use provision_customer when you need a token for one specific user.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| note | No | |
| seats | No | |
| total | No | |
| offset | Yes | |
| returned | Yes | |
| customers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, but the description adds real value beyond them: it discloses that access tokens are deliberately omitted from the response and explains why, and notes the `mcp_` naming convention. It does not cover result volume or pagination 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?
Three tight paragraphs, front-loaded with the core action, then the pre-provisioning rationale, then the token-omission caveat. Every sentence carries information an 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?
An output schema exists so return values need no explanation, and the description already covers the notable return quirk (no tokens). The remaining gap is pagination guidance for the limit/offset parameters, which an agent must infer from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two parameters (limit, offset), yet the description says nothing about pagination, page size, or how to page through results. With low coverage the description is expected to compensate, and it 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 the customers provisioned under this license') and adds a distinguishing detail — server-created customers are prefixed `mcp_` — that separates it from provision_customer and the track/stream 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?
Explicitly says to check here before provisioning because seats are limited, and names the alternative ('Use provision_customer when you need a token for one specific user'), giving both when-to-use and 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.
List the self-serve plans a company can subscribe to.
Needs no credentials. Use it to compare quotas against what the user
actually needs — get_capabilities shows what their current license
gives them, and the limits here show what each plan would give.
Note that a limit of 0 in these numbers means unlimited, not zero.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| plans | Yes | |
| how_to_subscribe | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent), but the description adds two genuinely non-obvious behaviors: no credentials are required, and a limit value of `0` means unlimited rather than zero. The latter is a critical interpretation rule that would otherwise cause misreading of results.
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 first, then usage and the sibling comparison, then the one caveat that matters. No filler, and the most surprising fact (0 = unlimited) is placed last where it stands out.
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 an output schema present and zero parameters, the description need only cover purpose, routing, and result interpretation — all of which it does. Nothing an agent needs to call or correctly read this tool 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; the schema is trivially complete. The description correctly focuses on output interpretation rather than inventing parameter guidance.
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 ('List') and resource ('self-serve plans a company can subscribe to'), and scopes it to self-serve rather than all plan types. An agent can distinguish this from sibling catalog tools like get_capabilities 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 when to use it ('compare quotas against what the user actually needs') and routes to the complementary sibling: get_capabilities for the current license vs. this tool for each plan's limits. It also states the precondition (no credentials needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the music channels available for generation and streaming.
Playlists are a three-level taxonomy addressed by playlist_index:
"6" is a whole category, "6.4" a group, "6.4.0" a single channel.
Broader indices mix more variety. Pass the index to generate_track or
start_stream.
Prefer a playlist over a text prompt when the brief maps cleanly onto a genre or mood: playlist generation can be served instantly from the pre-baked store, whereas prompts always cost a full render.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Case-insensitive substring filter over category/group/channel names, e.g. 'lofi' or 'cardio'. Omit to get the whole taxonomy. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| playlists | Yes | |
| how_to_use | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, so the bar is lower. The description adds genuine behavioral context: broader indices mix more variety, and playlist-served generation is instant versus a full render. It doesn't discuss any caching or freshness caveats of the pre-baked store, but the safety and cost profile is well conveyed.
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 paragraphs, front-loaded with the purpose, then taxonomy, then the usage preference. Each sentence carries information. Slightly dense but nothing 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?
With an output schema present, return values need not be explained. The description covers the search filter intent, the index taxonomy, and the generate-vs-prompt tradeoff—everything an agent needs to invoke 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 coverage is 100% for the single `search` param, so the baseline is 3. The description adds meaning beyond the schema by explaining the `playlist_index` addressing format used by generate_track and start_stream, which is the whole point of listing these channels—this is useful cross-tool semantics.
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 music channels'), and goes further by defining the three-level taxonomy addressing scheme. It clearly distinguishes itself from consumers like generate_track and start_stream by naming them as downstream users of the indices it returns.
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 tells the agent when to prefer a playlist over a text prompt ('when the brief maps cleanly onto a genre or mood') and gives the reason (instant pre-baked store vs. full render cost). This is actionable routing guidance, not vague context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tracks generated by this client, newest first by default.
Use it to recover a track id you lost, or to check what already exists before generating something similar.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| order | No | asc or desc. | |
| offset | No | ||
| order_by | No |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| total | No | |
| offset | Yes | |
| tracks | Yes | |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the default sort order ('newest first'), which is genuine behavioral context, but says nothing about pagination behavior, result caps, or whether the list is exhaustive across the client.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with what it does, then how to use it. Zero filler; every clause carries 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?
An output schema exists, so return values need no explanation. The description covers scope, default ordering, and usage intent. The gap is pagination/ordering semantics (order_by), but for a read-only list tool with a rich schema this is close to complete.
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 only 25% -- order has 'asc or desc' but order_by, limit, and offset are bare types. The description hints at ordering via 'newest first by default' but never explains order_by's accepted values, which is the biggest gap. Partial compensation only.
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 with scope qualifier: 'List tracks generated by this client, newest first by default.' The client-scoping and default ordering distinguish it from get_track (single fetch) and search_library (broader query), 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?
Explicit when-to-use: 'recover a track id you lost' and 'check what already exists before generating something similar' ties it to generate_track/regenerate_similar workflows. No when-not guidance or named alternatives, so it stops 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.
Get a Stripe billing-portal link for the connected company.
This is where a user changes plan, updates a card, downloads invoices, or cancels. Prefer it over doing any of that through tools — Stripe's own flow has the confirmations and the audit trail.
| Name | Required | Description | Default |
|---|---|---|---|
| redirect_url | No | Where Stripe returns the user afterwards. |
| Name | Required | Description |
|---|---|---|
| security | Yes | |
| next_step | Yes | |
| portal_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds real behavioral context beyond that: the call yields a hand-off link into Stripe's own hosted flow where the actual mutations happen, and that flow supplies confirmation and audit semantics the agent shouldn't reimplement.
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 what it returns, then what it's for, then the routing preference. No restatement of the name/title and 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 single-optional-param tool with an output schema, the description covers purpose, usage preference, and the key behavioral fact that the real work happens in Stripe's hosted flow. Return-value details are rightly left to the output schema; only the redirect_url's behavior on the hand-off is unaddressed.
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 optional redirect_url is already documented in the schema as 'Where Stripe returns the user afterwards.' The description adds no format, validation, or fallback guidance for it, 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+resource ('Get a Stripe billing-portal link') and immediately pins the scope to the 'connected company.' The second sentence clarifies what the returned link is for (plan changes, card updates, invoice downloads, cancellation), which separates it from generic link/mutation 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?
Gives an explicit routing rule: prefer this over performing plan/card/invoice/cancel actions through other tools, with a reason (Stripe's confirmations and audit trail). It stops short of naming when NOT to use it (e.g., vs. create_checkout_link for first-time purchases), so it is strong context without full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create Mubert credentials for one of your product's users.
Returns a customer_id and access_token for that user to call the API
with directly. Each customer gets its own quota slice and its own live
stream, which is why a multi-user product should not share one.
Safe to call repeatedly: the API is find-or-create, so an existing
custom_id returns the existing customer rather than failing. A genuinely
new one consumes a seat against the license's customer limit.
You do not need this to generate music through this server — it already has a customer of its own.
| Name | Required | Description | Default |
|---|---|---|---|
| custom_id | Yes | Your own identifier for the end user, e.g. the user id in your product. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| security | Yes | |
| custom_id | No | |
| expires_at | No | |
| how_to_use | Yes | |
| customer_id | Yes | Send as the `customer-id` header. |
| access_token | Yes | Send as the `access-token` header. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it explains the find-or-create semantics keyed on custom_id, that a genuinely new customer consumes a seat against the license's customer limit, and that the call returns customer_id and access_token. This is exactly the operational context annotations 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 idempotency, then the optionality caveat. Slightly long with four short paragraphs, but each carries distinct, non-redundant 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 one-parameter mutation whose return values are covered by the output schema, this description supplies idempotency, quota/seat implications, and the scope caveat. Nothing material 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, but the description adds meaning by tying custom_id to the find-or-create behavior ('an existing custom_id returns the existing customer rather than failing'), which is more than the schema's own description offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create Mubert credentials for one of your product's users.' It clearly distinguishes the tool from siblings like generate_track and list_customers by naming the artifact produced (customer credentials).
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 clear when-to-use rationale (each customer gets its own quota slice and live stream, so multi-user products should not share one) and an explicit when-not ('You do not need this to generate music through this server'). It does not name specific sibling alternatives, but the guidance is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a variation on an existing track.
This is a NEW track with a new id, and it consumes quota exactly like a fresh generation. The original is untouched. Do not use it to "tweak" something for free — check the remaining quota first if it is tight.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| format | No | ||
| bitrate | No | ||
| duration | Yes | Length in seconds, at least 5. Durations of 5, 6, 8, 10, 15, 20, 30, 40, 60, 180, 240, 300 can be served instantly from the pre-rendered store when generating from a playlist_index without bpm/key; any other value always costs a full render. The upper bound is per-license — see get_capabilities. | |
| track_id | Yes | Id of an existing track. | |
| intensity | No | ||
| wait_seconds | No |
| Name | Required | Description |
|---|---|---|
| bpm | No | |
| key | No | |
| url | No | Download link once done. |
| mode | No | |
| format | No | |
| prompt | No | |
| status | Yes | done, failed or pending. |
| bitrate | No | |
| duration | No | |
| track_id | No | |
| important | No | |
| expires_at | No | After this the audio is deleted and the URL stops working. |
| session_id | No | |
| edited_from | No | The track this one was derived from. Edits and variations never modify the original — they mint a new track, and this is the link back. |
| playlist_index | No | |
| how_it_was_served | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: a new id is created, the original is untouched, and it consumes quota exactly like a fresh generation. This clarifies the cost model and non-destructive relationship to the source track, which the readOnlyHint/destructiveHint flags do not convey on their own.
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, then the cost/id semantics. No filler and nothing repeated from the schema or annotations.
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?
Output schema exists so return values need not be described, and the quota behavior is well covered. But for a 7-parameter tool with low schema coverage, the near-total silence on generation parameters leaves real gaps an agent must resolve by reading the 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 only 29% across 7 parameters, yet the description says nothing about mode, format, bitrate, intensity, wait_seconds, or how duration interacts with the pre-rendered store. Only track_id/duration are indirectly implied; the description does not compensate for the coverage gap.
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 a variation on an existing track), which is clearer than the title alone. It implicitly separates itself from generate_track / generate_track_instant by operating on an existing track, but never names those siblings, so differentiation is inferred rather than explicit.
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 clear when-not ('Do not use it to tweak something for free') and a prerequisite (check remaining quota if tight). It stops short of naming the alternative tool for the edit/tweak case (e.g. edit_track), so routing is only partially closed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Jump the running stream to fresh music from the same playlist.
Use it when the current material has worn out but the channel is still right. The URL does not change, so the player keeps playing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | |
| loop | No | |
| note | No | |
| seconds | No | |
| intensity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true. The description adds genuinely useful behavioral context beyond that: the URL is unchanged so the player keeps playing, i.e. the stream endpoint survives the jump. It does not say what is lost (playback position, queued track), so it stops short of full disclosure.
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 what happens, then when to use it, then the user-visible effect. Every sentence adds distinct information 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?
With an output schema present and no parameters, the description covers the essentials: what changes, when to invoke, and that the listening URL is stable. The one gap is the fate of the current track/queue at the moment of the jump, which an agent might want to set expectations around.
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?
Zero parameters, so per the baseline the schema carries no semantic burden and the description need not document inputs. Nothing about the (empty) parameter set is misrepresented.
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: it jumps an already-running stream to fresh music from the same playlist. It implicitly contrasts with start_stream (stream must already be running) but never names that sibling or any other, so differentiation is left to inference.
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 condition: use it when the current material has worn out but the channel is still right. That is clear context for when to call it, but it offers no exclusions or named alternatives (e.g., versus start_stream or regenerate_similar).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Mubert's pre-made royalty-free catalogue.
This is free — it consumes no generation quota — so reach for it before generating whenever an existing track would do. All filters combine with AND. Call get_library_filters first to learn which values exist.
Every result is cleared for commercial use.
| Name | Required | Description | Default |
|---|---|---|---|
| bpm | No | ||
| key | No | Musical key, e.g. 'C', 'F#', 'Am', 'D#m'. | |
| mode | No | ||
| limit | No | ||
| moods | No | ||
| genres | No | ||
| offset | No | ||
| themes | No | ||
| duration | No | ||
| playlists | No | ||
| activities | No | ||
| instruments | No |
| Name | Required | Description |
|---|---|---|
| total | No | |
| offset | Yes | |
| tracks | Yes | |
| returned | Yes | |
| trial_cap | No | Set when a trial license silently discarded the filters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by disclosing cost behavior (consumes no generation quota), which annotations don't cover. Also discloses AND-combination semantics for filters and the commercial-licensing status of results. Doesn't cover pagination behavior, though limit/offset params exist.
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 short sentences, each earning its place: purpose, cost/routing, filter semantics, and licensing. Front-loaded with the core purpose and the most decision-relevant fact (free).
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?
Output schema exists, so return values needn't be explained. However, with 12 parameters at 8% schema coverage, an agent cannot construct a working query without external documentation. The get_library_filters pointer mitigates value discovery but not query shape, leaving a real 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 only 8% with 12 parameters, so the description must carry significant weight but adds almost nothing: only the AND-combination note and 'all filters combine'. It never explains what bpm, moods, genres, themes, activities, instruments, playlists, duration, mode, or the pagination params accept or how string filters are formatted.
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 (Search) and resource (Mubert's pre-made royalty-free catalogue), and explicitly distinguishes from the generation siblings by noting it's free and should be reached for before generating. An agent can tell it apart from generate_track and get_track 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?
Explicitly states when to use it ('reach for it before generating whenever an existing track would do') and names the alternative workflow (generating). It also directs the agent to call get_library_filters first, which is concrete sequencing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the energy of the running stream without interrupting playback.
This is the point of streaming over generated tracks: the arrangement adapts live. Use it to follow a workout's phases or a game's tension.
| Name | Required | Description | Default |
|---|---|---|---|
| intensity | Yes | low for calm and ambient, medium for balanced, high for driving. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| loop | No | |
| note | No | |
| seconds | No | |
| intensity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full profile (mutation, idempotent, open-world, destructiveHint=true), so the bar is lower. The description usefully adds that the change applies live without interrupting playback, but this sits oddly against destructiveHint=true and it says nothing about persistence across streams, permissions, or latency.
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 operative instruction is front-loaded in the first sentence. The middle sentence ('This is the point of streaming over generated tracks...') is motivational filler rather than actionable content, though it is short.
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 tool with an output schema present, the essentials are covered and return values need not be explained. The main omission is the precondition of an active stream and what happens if none exists.
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 'intensity' parameter already documents low/medium/high with their meanings. The description adds no value-mapping or format detail beyond that, 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 ('Change the energy of the running stream') plus a scoping qualifier ('without interrupting playback') that separates it from start_stream, restart_stream, and set_stream_loop. It never names those siblings explicitly, so differentiation is inferential rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It offers concrete use cases ('follow a workout's phases or a game's tension'), which implies context, but gives no when-not guidance and no comparison to the sibling streaming tools. The precondition that a stream must already be running is only implied by 'the running stream'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make the running stream loop a section, or stop looping.
Useful for holding a mood over a fixed moment — a menu screen, a pause, an interstitial — without cutting to a different track.
| Name | Required | Description | Default |
|---|---|---|---|
| loop | Yes | 'on' or 'off'. | |
| seconds | No | Loop length in seconds, when turning it on. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| loop | No | |
| note | No | |
| seconds | No | |
| intensity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (not readOnly, idempotent, destructive, openWorld), so the bar is lower. The description adds a useful behavioral nuance — that looping holds the current track rather than 'cutting to a different track' — but it never explains what the destructiveHint entails, e.g. whether the previous loop state is lost or what happens on 'off'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with zero filler. The core action is stated first and the rationale second, so an agent gets the essential meaning immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, and both parameters are fully covered by the schema. The description supplies purpose plus a concrete use case, leaving only the interaction with sibling stream controls unaddressed.
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 both 'loop' and 'seconds' fully documented in the schema, so the baseline is 3. The description adds no syntax or format detail beyond what the schema already provides.
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 ('Make the running stream loop a section, or stop looping') and covers both the on and off states. An agent can tell this controls stream looping, but the description never distinguishes it from the closely related siblings set_stream_intensity, start_stream, and restart_stream.
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 second sentence supplies a usage context (holding a mood over a menu screen, pause, or interstitial), which implies when this tool is appropriate. However, there is no explicit 'when not' and no routing to alternatives such as set_stream_intensity or start_stream, leaving the agent to infer the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open an endless, non-repeating music stream and return its URL.
Use this instead of generating tracks when the music should never stop and never loop — a workout app, a game, a focus tool, a venue.
Only one stream exists per client at a time: calling this again replaces the running one rather than opening a second. Streaming is metered by seconds played, and metering is reported after the fact, so a quota can be overshot slightly.
| Name | Required | Description | Default |
|---|---|---|---|
| bitrate | No | ||
| intensity | No | low, medium or high. Changeable later. | |
| stream_type | No | 'http' for a normal audio player, 'webrtc' for low latency. | http |
| playlist_index | Yes | Channel from list_playlists, e.g. '4.0.0'. |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| type | Yes | |
| security | Yes | Why this URL must be handled as a credential. |
| stream_url | Yes | |
| playlist_index | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive=true, idempotent=false and openWorld=true; the description reinforces and explains this with 'calling this again replaces the running one rather than opening a second', and adds non-obvious billing behavior — metered by seconds played, reported after the fact, quota can be overshot.
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 action and return value, then two tight paragraphs covering the when-to-use case and the runtime constraints. No filler sentences; every clause carries operational meaning.
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 an output schema present, return shape need not be explained, yet the URL is still mentioned. The single-stream, replace-on-recall and metered-billing details give an agent everything needed to call this correctly and anticipate side effects.
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 75%, with intensity, stream_type and playlist_index documented in the schema and bitrate left undocumented in both places. The description adds no parameter-level detail (types, units, defaults), so it does not compensate for the gap or exceed 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 and resource ('Open an endless, non-repeating music stream') plus the return value ('return its URL'), and implicitly contrasts with the generate_track family by emphasizing a continuous stream rather than discrete tracks.
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 'use this instead of generating tracks when the music should never stop and never loop', then enumerates concrete scenarios (workout app, game, focus tool, venue). The alternative and the selecting condition are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keep waiting for a generation that had not finished yet.
Call this when a generation tool came back with status: pending. It
costs no quota — the track is already paid for. Never start a second
generation for the same brief instead of calling this.
| Name | Required | Description | Default |
|---|---|---|---|
| track_id | Yes | Id returned by a generation tool. | |
| wait_seconds | No |
| Name | Required | Description |
|---|---|---|
| bpm | No | |
| key | No | |
| url | No | Download link once done. |
| mode | No | |
| format | No | |
| prompt | No | |
| status | Yes | done, failed or pending. |
| bitrate | No | |
| duration | No | |
| track_id | No | |
| important | No | |
| expires_at | No | After this the audio is deleted and the URL stops working. |
| session_id | No | |
| edited_from | No | The track this one was derived from. Edits and variations never modify the original — they mint a new track, and this is the link back. |
| playlist_index | No | |
| how_it_was_served | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world safety, so the bar is lower; the description adds genuinely new context by noting it costs no quota because the track is already paid for. It does not describe what happens if the track is still pending when the wait elapses, so it falls just short of full behavioral disclosure.
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, zero filler, with the triggering condition stated first and the anti-pattern warning last. 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?
An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, the undefined wait_seconds behavior and the unstated outcome when the wait expires leave a real gap for a long-polling 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 only 50%: track_id is documented in the schema, but wait_seconds has no description in either place. The description never mentions wait_seconds, its default of 120, or the 600 upper bound, so it fails to compensate for the coverage gap on a parameter whose semantics (blocking duration/timeout) matter to correct invocation.
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 action (keep waiting on a generation) and the exact triggering state (a generation tool returned status: pending). It also explicitly disambiguates from the sibling generation tools by warning against starting a second generation for the same brief.
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 gives an explicit when-to-use condition ('Call this when a generation tool came back with status: pending') and an explicit when-not ('Never start a second generation for the same brief instead of calling this'), the latter directly naming the alternative behavior an agent might otherwise choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_checkout_linkdelete_customeredit_trackgenerate_trackgenerate_track_instantget_capabilitiesget_library_filtersget_tracklist_customerslist_planslist_playlistslist_tracksopen_billing_portalprovision_customerregenerate_similarrestart_streamsearch_libraryset_stream_intensityset_stream_loopstart_streamwait_for_track
Add one secure layer between your agents and this server.