Search and license 5,000+ fully cleared music tracks via MCP. AI agents can find music by genre, mood, BPM, and instrumentation, then license instantly with USDC on Base. No human in the loop. Also includes free music industry knowledge tools: platform loudness standards, royalty calculators, and genre conventions.
Scored across 13 tools
The four calculate_* tools each target a distinct deal type (co-writer, producer points, songwriter/publisher, sync), and the license lifecycle tools (get_license_options, initiate_license, verify_license) are cleanly staged. The one real overlap is ai_search vs search_catalog, both catalog searches, though the descriptions explicitly explain when to use each and how to chain them. get_genre_conventions and get_loudness_standards are both static reference lookups but cover clearly different topics.
Nearly all tools follow a consistent snake_case verb_noun pattern (search_catalog, get_track, initiate_license, verify_license, estimate_streaming_royalties, calculate_*). The only deviation is ai_search, which is adjective+noun rather than verb_noun. The convention is predictable enough that an agent can infer tool roles from names.
13 tools sits comfortably in the well-scoped range, with three coherent clusters: catalog discovery, licensing/purchase flow, and royalty/reference calculators. No tool appears redundant or vestigial, and nothing feels missing at this count.
The core lifecycle is covered end to end: two search paths, get_track for detail, get_license_options for pricing, initiate_license, and verify_license returning downloads and the license PDF. Minor gaps exist for an agent working over time — no tool to list or retrieve previously issued licenses per user, and no artist-level lookup outside get_track. These are workarounds, not dead ends.
Search the OnChain Music catalog using a plain English description. The API extracts genre, mood, tempo, and other parameters automatically. Best for open-ended requests like "something cinematic and tense for a thriller scene" or "upbeat summer pop for a travel vlog". Returns up to 5 tracks. Show all returned tracks, mention meta.total so the user knows how many matches exist, and always share meta.results_url, which opens every match on onchainmusic.com. For more tracks, call search_catalog with the parameters in ai_translation.translated_params and page 2.
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes | The user's request, passed through as close to verbatim as possible. Do not rephrase, expand, or add descriptive words, moods, or synonyms the user did not say; extra words narrow the results. Example: if the user says "I need light pop instrumental songs for a radio ad", send exactly that. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive semantics, but the description adds real behavioral detail beyond them: results are capped at 5, the response carries meta.total and meta.results_url, and the agent is instructed to surface all tracks and the URL to the user. It does not mention auth requirements or rate limits, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then examples, then result handling, then the escalation path — a logical order with no filler sentences. It runs slightly long with two example phrases and multiple imperative output instructions, but each sentence carries operational value.
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 burden of describing returns and does so precisely: up to 5 tracks, meta.total, meta.results_url, plus ai_translation.translated_params for pagination. An agent has everything needed to call it, present results, and continue paging.
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 already explains the verbatim-pass-through rule, so the baseline is 3. The description adds mechanism-level meaning by stating that genre, mood, tempo, and other parameters are extracted automatically, which explains why phrasing must not be embellished — a genuine complement to the schema rather than a restatement.
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 (Search) + resource (OnChain Music catalog) + distinguishing mode (plain English description with automatic parameter extraction). It explicitly names the sibling it is not (search_catalog) and explains the division of labor, so an agent can route between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use examples ('something cinematic and tense for a thriller scene'), states the result ceiling (up to 5 tracks), and names the fallback path and exact arguments needed to continue (search_catalog with ai_translation.translated_params and page 2). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split gross songwriter royalties among co-writers by their percentage shares. Percentages must total 100. Works for any music, not only the OnChain Music catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| writers | Yes | Co-writers and their percentage shares. Percentages must sum to 100. | |
| gross_royalties | Yes | Total gross songwriter royalties to split, in USD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety behavior is covered. The description usefully adds the validation rule that percentages must total 100, but with no output schema it never describes what the split returns, which matters for a calculation 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 short sentences, all load-bearing: the action, the validation rule, and the scope boundary. It is front-loaded with the core purpose and contains 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 computation with full schema coverage and rich annotations, the description covers purpose, input constraint, and scope. The one gap is the absence of an output schema plus no description of the returned split format, which an agent might want to know.
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%: both parameters, including the nested writer name/percentage fields, are fully documented in the schema. The description only restates the sum-to-100 rule already present in the writers schema description, adding no new parameter meaning.
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 ('Split') and resource ('gross songwriter royalties among co-writers by their percentage shares'), which is clear and concrete. It implicitly differs from siblings like calculate_songwriter_publisher_split and calculate_sync_fee_split through the resource named, but it never explicitly contrasts with the nearest 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?
The description gives a scope statement ('Works for any music, not only the OnChain Music catalog') and an input constraint, which implies when the tool applies, but it never says when to choose this over calculate_songwriter_publisher_split or calculate_producer_points. Usage must be inferred from the tool name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate per-unit and total earnings for a producer points deal: the master royalty, the producer's share, and the artist's net. Works for any music, not only the OnChain Music catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| units_sold | No | Units sold. When provided, totals are included. | |
| producer_points | Yes | Producer points as a percentage of the base price. Example: 3 for 3 points. | |
| master_royalty_rate | No | Artist master royalty rate as a percentage (0-100). Defaults to 18. | |
| suggested_retail_price | No | Base price per unit in USD. Defaults to 9.99. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's burden is lighter. It adds real value by naming the three values the tool computes — master royalty, producer's share, artist's net — which is the return content, and there is no output schema to carry that. It does not mention error behavior for out-of-range inputs, keeping it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and output list, then a short scoping clause. No filler and nothing redundant with 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?
With no output schema, the description usefully names the three returned figures, and the parameter defaults/ranges live in the schema. A pure arithmetic tool with full annotation coverage needs little more, though a note on input validity or rounding/currency assumptions 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%, with each of the four parameters documented, including defaults for master_royalty_rate (18) and suggested_retail_price (9.99). The description mentions 'per-unit and total earnings,' which loosely maps to the units_sold conditional-total behavior, but adds no new syntax or meaning. Baseline 3 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?
Names a specific verb (calculate) and resource (producer points deal) and enumerates the three computed outputs: master royalty, producer's share, artist's net. It also distinguishes itself from the catalog-bound siblings by stating it works for any music, so an agent can separate it from get_track/search_catalog-driven flows 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?
The phrase 'producer points deal' and 'works for any music, not only the OnChain Music catalog' imply the usage context, but the description never states when to pick this over calculate_cowriter_split or calculate_songwriter_publisher_split, nor any prerequisites. Usage is inferable from the domain term rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split gross songwriter royalties between the songwriter and publisher, and describe the deal type (self-published, co-publishing, full publishing). Works for any music, not only the OnChain Music catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| gross_royalties | Yes | Total gross royalties collected, in USD. | |
| publisher_percentage | No | Publisher's percentage of the songwriter share (0-100). Defaults to 50 for a standard co-publishing deal. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the burden is light. The description adds value beyond them by disclosing that the tool also returns a deal-type classification and that its scope extends beyond the OnChain catalog. It stops short of explaining rounding, currency handling, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, front-loaded with the primary action. The trailing scope sentence earns its place by preempting a catalog-applicability question, though it reads as slightly appended rather than integrated.
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 sketches the return (a split plus a deal-type label). For a two-parameter, read-only calculation tool this is close to complete, though it does not explain how the three deal types affect the split numerically.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both gross_royalties and publisher_percentage (including the default of 50 for co-publishing) are already documented in the schema. The description adds no parameter-level 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?
States a specific verb (split) and resource (gross songwriter royalties), plus a secondary output (deal type: self-published, co-publishing, full publishing). This clearly distinguishes it from the sibling calculators calculate_cowriter_split and calculate_sync_fee_split, which handle different royalty parties.
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 line 'Works for any music, not only the OnChain Music catalog' gives useful scope guidance about applicability, but it never states when to choose this tool over calculate_cowriter_split or calculate_producer_points, nor any prerequisites. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a sync licensing fee between the master rights side and the publishing side, then split the publishing side between publisher and songwriter. Works for any music, not only the OnChain Music catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| sync_fee | Yes | Total sync licensing fee, in USD. | |
| master_owner_percentage | No | Master rights owner's share of the fee (0-100). Defaults to 50. | |
| publisher_sync_percentage | No | Publisher's share of the publishing side (0-100). The rest goes to the songwriter. Defaults to 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description usefully adds the scope caveat about working outside the OnChain catalog and discloses the internal allocation order, but omits rounding/precision behavior and how defaults interact with the split.
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, front-loaded with the core operation, followed by the scope note. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only calculator with no output schema, the description explains the entire computation chain well enough for an agent to predict the result. Minor gaps around units already in schema and rounding are negligible.
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 all three parameters are already documented with ranges and defaults. The description's mention of the publishing-side split loosely maps to publisher_sync_percentage but adds no format or edge-case detail 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 (split) and resource (sync licensing fee) and lays out the two-stage allocation logic, so the operation is unambiguous. It does not explicitly contrast itself with the closely related sibling calculate_songwriter_publisher_split, which performs one of the sub-steps described here.
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 note that it 'works for any music, not only the OnChain Music catalog' implicitly signals scope, and the sync-fee framing implies when it applies. However there is no explicit when-to-use vs. when-not guidance against siblings like calculate_songwriter_publisher_split or calculate_cowriter_split.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate low, mid, and high streaming payouts for a number of streams on a platform, before and after the artist royalty rate. Estimates use publicly reported averages; actual payouts vary. Works for any music.
| Name | Required | Description | Default |
|---|---|---|---|
| streams | Yes | Number of streams. | |
| platform | No | Streaming platform. Use "average" for a blended estimate. Defaults to average. | |
| artist_royalty_rate | No | Artist royalty rate as a percentage of label revenue (0-100). Use 100 for independent artists keeping all revenue. Defaults to 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, so the bar is low. The description nonetheless adds real behavioral context the annotations cannot: estimates derive from publicly reported averages, outputs are ranges (low/mid/high) reflected both pre- and post-royalty, and actual payouts will vary.
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 core action and output shape. The caveat about averages/actual payouts sits where an agent will read it; the trailing 'Works for any music' is mildly expendable but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully discloses the return structure (low/mid/high, pre- and post-royalty) and the accuracy caveat. Combined with annotations and full schema coverage, an agent has enough to invoke it correctly; only explicit alternative-selection guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents streams, platform (including "average"), and artist_royalty_rate with its 0-100 range and default. The description restates these at a high level ('a number of streams on a platform, before and after the artist royalty rate') without adding format or edge-case detail, matching the baseline 3 when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Estimate) plus the exact resource (streaming payouts) and the output shape (low/mid/high, before and after royalty rate). This is clearly distinguishable from sibling calculators like calculate_cowriter_split or calculate_sync_fee_split, which deal with splits rather than streaming revenue.
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 implies the use case (roughly valuing a number of streams on a platform) and notes it works for any music, but never states when to prefer it over alternatives or any exclusions. No prerequisite or when-not guidance is offered, so the agent must infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns music industry conventions for a given genre including typical BPM ranges, song structure, instrumentation, key tendencies, production characteristics, and common sync use cases. Useful for songwriting, production decisions, A&R research, playlist curation, and sync licensing briefs. Works for any music — not limited to the OnChain Music catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| genre | Yes | The genre to look up. Examples: Pop, Rock, Hip-Hop, Electronic, Jazz, Country, R&B, Classical, Indie, Metal, Folk, Latin, Reggae, Blues, Soul, Funk, Ambient, House, Techno, Drum and Bass, Trap, Lo-Fi. | |
| include_sync_uses | No | If true, includes common sync licensing use cases for the genre (TV, film, advertising contexts). Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the useful scope fact that this is an open-domain reference covering any genre, not just the internal catalog, but says nothing about unknown-genre handling or the shape of the response. With annotations doing the heavy lifting, a 3 is appropriate.
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 sentences, front-loaded with the payload before the use cases, and no filler. The use-case enumeration is slightly long but each item is informative rather than decorative.
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 does the work of describing return content in detail, and annotations cover safety. What remains unstated is edge behavior (unknown or ambiguous genre strings) and whether results are a fixed dataset or generated, which keeps it just under fully 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 description coverage is 100% – both 'genre' (with an example list) and 'include_sync_uses' (with default and meaning) are fully documented in the schema. The description only indirectly gestures at sync use cases via its content list, 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 ('Returns music industry conventions for a given genre') and enumerates the exact payload (BPM ranges, structure, instrumentation, keys, production, sync uses). The line 'not limited to the OnChain Music catalog' separates it from the catalog/royalty siblings without the agent opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage contexts (songwriting, production decisions, A&R research, playlist curation, sync briefs) and clarifies scope ('works for any music'), which is clear routing guidance. It stops short of naming an alternative or stating when NOT to reach for it versus sibling lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List license options with prices in USD. "personal" has the non-commercial licenses (social_media, all_digital) to use as license_type. "business" is the rate card: medium (for example Social Media Branded Content, Commercials, Film), category, territory, and term. Pass track_id to get that track's exact prices and whether it can be licensed. Use the chosen options with initiate_license.
| Name | Required | Description | Default |
|---|---|---|---|
| track_id | No | Optional. Track id from search, for example "417" or "partner_82". Adds this track's price to every option. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a safe, read-only, idempotent lookup. The description adds useful behavioral context by explaining that "personal" covers non-commercial license types while "business" returns rate-card dimensions such as medium, category, territory, and term, and that track_id adds exact prices and licensability. It does not discuss pagination or output shape, but the annotations carry the safety profile.
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 remains tightly structured. Each sentence adds useful information about license types, track_id behavior, or the next step with initiate_license, 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 simple read-only lookup with one optional parameter and no output schema, the description gives enough context about what is returned: personal license types, business rate-card dimensions, and track-specific pricing/licensability. It also connects the result to initiate_license, making the workflow clear.
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 would be 3. The description adds meaning beyond the schema by explaining that track_id yields that track's exact prices and whether it can be licensed, not just that it adds price to every option.
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 uses a specific verb and resource: "List license options with prices in USD." It also clarifies the two option families (personal vs. business) and ties the output to the sibling initiate_license, so an agent can distinguish this from search/catalog tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the key usage condition for track_id: pass it to get that track's exact prices and licensability. It also says to use the chosen options with initiate_license. There is no explicit when-not-to-use guidance or comparison against other sizing/verification siblings, 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.
Returns the official loudness normalization standards for major music and video platforms. Includes integrated LUFS target, true peak limit, and short-term LUFS where applicable. Useful for mastering decisions, mix prep, and ensuring tracks meet platform requirements before distribution or licensing. Works for any music — not limited to the OnChain Music catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Optional. Filter to a specific platform. Examples: Spotify, Apple Music, YouTube, TikTok, Netflix, Amazon Music, Tidal, SoundCloud, Podcast. Leave empty to return all platforms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and a closed (openWorldHint=false) static dataset. The description adds value beyond that by stating the exact metrics returned and clarifying scope (applies to any music, not just the catalog), which tells the agent this is a general-purpose reference lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences, front-loaded with the core purpose before the use cases. Nothing is redundant, though the final scoping sentence could arguably be trimmed.
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 by naming the specific standards (LUFS targets, true peak limit). An agent has enough to invoke and interpret it, though field-level return structure is not spelled out.
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 single optional 'platform' parameter is fully documented in the schema (100% coverage) with examples and empty-string behavior. The description adds no parameter detail beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the official loudness normalization standards for major music and video platforms') and enumerates what is returned (integrated LUFS, true peak, short-term LUFS). The closing line explicitly distinguishes it from catalog-bound siblings by noting it 'works for any music — not limited to the OnChain Music catalog.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete use contexts: mastering decisions, mix prep, and meeting platform requirements before distribution or licensing. No explicit when-not or named alternative, but no sibling overlaps this static-reference function, so the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full metadata for a specific track from the OnChain Music catalog or a partner catalog, including license pricing, available download formats, artist information, BPM, key, mood, and license terms. Use this after search_catalog or ai_search to confirm details before licensing. Pass the track id exactly as returned by search, including the "partner_" prefix for partner tracks.
| Name | Required | Description | Default |
|---|---|---|---|
| track_id | Yes | The track id exactly as returned by search_catalog or ai_search, for example "417" or "partner_82". Never remove the "partner_" prefix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, non-destructive, so safety is covered. The description adds real behavioral context beyond that: the tool spans two catalog types and requires the exact id including the 'partner_' prefix, a quirk with real failure consequences. No return format or pagination notes, but for a single-record read that is a minor gap.
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 verb and resource, then the return fields, then usage. Tight overall, though the 'partner_' prefix instruction is stated twice (once in the description, once in the schema), which is mild redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey return values, and it does by listing the metadata fields (pricing, formats, artist, BPM, key, mood, terms). Combined with the id-passing caveat, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is fully described, so the schema carries the load. The description repeats the 'partner_' prefix constraint already present in the schema description, adding essentially nothing new. Baseline 3 for fully documented params.
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?
Uses a specific verb (Retrieve) with a precise resource (full metadata for a specific track) and enumerates the returned fields (license pricing, formats, artist info, BPM, key, mood, license terms). It also distinguishes the two catalog scopes (OnChain vs partner), so the agent can separate it from search_catalog or ai_search.
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 ('after search_catalog or ai_search to confirm details before licensing') and names both upstream alternatives. This routes the agent clearly: search first, then confirm with get_track before licensing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a license purchase for any track, including partner tracks. First ask whether the license is personal (non-commercial) or business. Personal: pass license_type (social_media or all_digital). Business: pass licensee_type "business" with medium, category, territory, and term from get_license_options. Returns a payment_id (like "OCM-Q000123"), the exact USDC amount, the receiving wallet on Base (chain ID 8453), and a terms_url for the license agreement. Before the user pays, confirm the track title and artist in track_to_confirm and the price with them. The user must send the exact amount from the paying_wallet given here; no memo is needed. After the user confirms they sent payment, call verify_license with the payment_id.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | Business licenses: term from get_license_options. | |
| No | Optional. Email to receive the license and download links. | ||
| usage | No | Optional. Short description of how the music will be used. | |
| medium | No | Business licenses: medium from get_license_options, for example "Social Media Branded Content". | |
| country | No | Optional. Two-letter country code of the licensee, for example "US". | |
| category | No | Business licenses: category from get_license_options. | |
| track_id | Yes | The track id exactly as returned by search_catalog, ai_search, or get_track, for example "417" or "partner_82". Never remove the "partner_" prefix. | |
| territory | No | Business licenses: territory from get_license_options. | |
| license_type | No | Personal (non-commercial) licenses: social_media (personal videos on TikTok, Instagram, YouTube, X) or all_digital (non-commercial use on websites, podcasts, streaming, and online video). Omit for business licenses. | |
| licensee_name | No | Optional. Person or company that will hold the license. Printed on the agreement. | |
| licensee_type | No | For rate card licenses (medium, category, territory, term): business (default) or personal. | |
| paying_wallet | Yes | The Base wallet address (0x followed by 40 hex characters) the user will send USDC from. | |
| project_title | No | Optional. Project or production title. Printed on the agreement. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering mutation, open-world, and non-idempotency, the description adds valuable process context: it returns a payment_id, exact USDC amount, receiving wallet on Base (chain 8453), and terms_url. It also warns that the user must send the exact amount with no memo and that confirmation must happen before payment. It does not discuss failure or retry behavior, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well front-loaded: the primary action and first question come first, followed by branch-specific parameter guidance and then the payment verification flow. Every sentence carries operational information, though it is longer and more prose-heavy than ideal for quick scanning.
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?
Given 13 parameters, no output schema, and a multi-step payment flow, the description is complete enough to execute correctly. It explains the return values (payment_id, amount, wallet, terms_url), the required user confirmation, and the next tool to call, so no critical context 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 schema already documents every field. The description goes beyond it by explaining the personal-vs-business branching logic and which parameters belong to each path, including that business fields must come from get_license_options. It also references track_to_confirm and paying_wallet in the confirmation workflow, adding practical meaning beyond field definitions.
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 opens with a specific verb+resource ('Start a license purchase') and scopes it to 'any track, including partner tracks.' It also distinguishes the tool from siblings by naming get_license_options for business parameters and verify_license as the follow-up step.
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 branching instructions: first ask personal vs. business; for personal use license_type; for business pass licensee_type plus rate-card fields from get_license_options. It also states the exact next action after payment (call verify_license), leaving no ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the OnChain Music catalog of 8,700+ independently owned, fully cleared songs, plus partner catalogs. Filter by genre, tempo, BPM, key, and instrumentation. Use the description parameter as the primary search field for style, mood, energy, and use-case words. Returns up to 5 tracks per call. Show all returned tracks, mention meta.total so the user knows how many matches exist, and always share meta.results_url, which opens every match on onchainmusic.com. For more tracks, call again with the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Musical key. Examples: C Minor, G Maj, A Minor, F Maj. | |
| page | No | Page number. Use 2, 3, and so on when the user asks for more tracks. | |
| genre | No | Genre filter. Examples: Rock, Hip-Hop, Electronica, Orchestral, Jazz, Country, R&B, Pop. | |
| bpm_max | No | Maximum BPM. Use with bpm_min to filter by tempo range. | |
| bpm_min | No | Minimum BPM. Use with bpm_max to filter by tempo range. | |
| keywords | No | Additional keyword search across track titles, artist names, and tags. | |
| subgenre | No | Subgenre filter. Examples: Indie, Deep House, Trap, Classical. | |
| description | No | PRIMARY search field. Pass style, mood, energy, instrumentation, or use-case words. Each word is searched individually across multiple fields. Example: "epic orchestral trailer" or "upbeat summer pop". | |
| instrumental | No | Yes = instrumental only (no vocals). No = has vocals. | |
| license_type | No | Show pricing for one personal (non-commercial) license type: social_media = Personal Social Media ($10 USDC): Personal, non-commercial videos on TikTok, Instagram, YouTube, X, Facebook, and similar platforms. all_digital = Personal All Digital ($35 USDC): Non-commercial use on websites, podcasts, streaming, and online video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful operational details beyond annotations: 8,700+ track scope, partner catalogs, a 5-track cap per call, pagination behavior, and required handling of meta.total and meta.results_url.
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 catalog scope and filter dimensions, then covers the primary search field, result cap, pagination, and output-handling instructions. The six sentences are compact and each carries operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter read-only search tool with no output schema, the description supplies catalog scope, primary query guidance, result cap, pagination instructions, and the important meta fields to surface. Filter-level details are left to the fully documented schema, leaving no critical gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and every parameter is documented with examples or enums. The description reinforces that description is the primary search field and page supports pagination, but this largely repeats what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Search the OnChain Music catalog of 8,700+ independently owned, fully cleared songs, plus partner catalogs,' and lists filter dimensions. It is clear what the tool does, but it does not explicitly distinguish itself from sibling ai_search.
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 usage context: use the description parameter as the primary search field, filter by genre/tempo/BPM/key/instrumentation, paginate with page, show all tracks, mention meta.total, and share meta.results_url. It does not name alternatives such as ai_search or get_track, or say when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a license payment has been confirmed on Base. Returns status "license_issued" with the license_number, download links for the available formats, and license_pdf_url, the license agreement PDF. Share the download links and then the license PDF link with the user, and tell them the links expire at links_expire_at. If the status is "awaiting_payment" or "payment_confirmed", tell the user and check again shortly. Confirmation usually takes 30 to 60 seconds. If the status is "expired", start a new license with initiate_license.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The payment_id returned by initiate_license, for example "OCM-Q000123". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, idempotent, open-world behavior, and the description adds substantial context beyond them: the status model, returned download and PDF links, link expiry field, expected confirmation timing, retry behavior, and the expired-license handoff. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then flows through return values, user guidance, timing, and failure handling. Every sentence 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?
There is no output schema, but the description explains the relevant statuses, returned fields, link expiry, expected timing, and next action on expiry. That is enough for an agent to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single payment_id parameter, including an example format and its origin from initiate_license. The description does not add further parameter semantics, so the baseline 3 is appropriate given 100% 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?
The description states a specific verb and resource: check whether a license payment has been confirmed on Base. It also enumerates the possible statuses and distinguishes the expired case from initiate_license, so the agent can tell what this tool does versus its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit operational guidance: if status is awaiting_payment or payment_confirmed, tell the user and check again shortly; confirmation usually takes 30-60 seconds; if expired, start a new license with initiate_license. This directly covers when to retry and when to use the alternative tool.
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.
search_catalog1 field changedInput schema / properties / license_type / descriptionPrevious value: -"Show pricing for one personal (non-commercial) license type: social_media = Personal Social Media ($1 USDC): Personal, non-commercial videos on TikTok, Instagram, YouTube, X, Facebook, and similar platforms. all_digital = Personal All Digital ($35 USDC): Non-commercial use on websites, podcasts, streaming, and online video."New value: +"Show pricing for one personal (non-commercial) license type: social_media = Personal Social Media ($10 USDC): Personal, non-commercial videos on TikTok, Instagram, YouTube, X, Facebook, and similar platforms. all_digital = Personal All Digital ($35 USDC): Non-commercial use on websites, podcasts, streaming, and online video."search_catalog1 field changedInput schema / properties / license_type / descriptionPrevious value: -"Show pricing for one personal (non-commercial) license type: social_media = Personal Social Media ($10 USDC): Personal, non-commercial videos on TikTok, Instagram, YouTube, X, Facebook, and similar platforms. all_digital = Personal All Digital ($35 USDC): Non-commercial use on websites, podcasts, streaming, and online video."New value: +"Show pricing for one personal (non-commercial) license type: social_media = Personal Social Media ($1 USDC): Personal, non-commercial videos on TikTok, Instagram, YouTube, X, Facebook, and similar platforms. all_digital = Personal All Digital ($35 USDC): Non-commercial use on websites, podcasts, streaming, and online video."search_catalog1 field changedInput schema / properties / license_type / descriptionPrevious value: -"Filter by intended license type. social_media = $5 USDC. all_digital = $35 USDC."New value: +"Show pricing for one personal (non-commercial) license type: social_media = Personal Social Media ($10 USDC): Personal, non-commercial videos on TikTok, Instagram, YouTube, X, Facebook, and similar platforms. all_digital = Personal All Digital ($35 USDC): Non-commercial use on websites, podcasts, streaming, and online video."initiate_license6 fields changedInput schema / properties / category / descriptionPrevious value: -"For other uses: category from get_license_options."New value: +"Business licenses: category from get_license_options."Input schema / properties / license_type / descriptionPrevious value: -"social_media (TikTok, Instagram, YouTube, X; non-commercial) or all_digital (advertising, apps, games, podcasts, websites). Omit when using medium, category, territory, and term."New value: +"Personal (non-commercial) licenses: social_media (personal videos on TikTok, Instagram, YouTube, X) or all_digital (non-commercial use on websites, podcasts, streaming, and online video). Omit for business licenses."Input schema / properties / licensee_typeAdded value: +{
+ "description": "For rate card licenses (medium, category, territory, term): business (default) or personal.",
+ "enum": [
+ "business",
+ "personal"
+ ],
+ "type": "string"
+}Input schema / properties / medium / descriptionPrevious value: -"For other uses: medium from get_license_options, for example \"Commercials\"."New value: +"Business licenses: medium from get_license_options, for example \"Social Media Branded Content\"."Input schema / properties / term / descriptionPrevious value: -"For other uses: term from get_license_options."New value: +"Business licenses: term from get_license_options."Input schema / properties / territory / descriptionPrevious value: -"For other uses: territory from get_license_options."New value: +"Business licenses: territory from get_license_options."get_license_optionsinitiate_license11 fields changedInput schema / properties / categoryAdded value: +{
+ "description": "For other uses: category from get_license_options.",
+ "type": "string"
+}Input schema / properties / countryAdded value: +{
+ "description": "Optional. Two-letter country code of the licensee, for example \"US\".",
+ "type": "string"
+}Input schema / properties / emailAdded value: +{
+ "description": "Optional. Email to receive the license and download links.",
+ "type": "string"
+}Input schema / properties / license_type / descriptionPrevious value: -"social_media ($5 USDC: TikTok, Instagram, YouTube, X) or all_digital ($35 USDC: advertising, apps, games, podcasts, websites)."New value: +"social_media (TikTok, Instagram, YouTube, X; non-commercial) or all_digital (advertising, apps, games, podcasts, websites). Omit when using medium, category, territory, and term."Input schema / properties / licensee_nameAdded value: +{
+ "description": "Optional. Person or company that will hold the license. Printed on the agreement.",
+ "type": "string"
+}Input schema / properties / mediumAdded value: +{
+ "description": "For other uses: medium from get_license_options, for example \"Commercials\".",
+ "type": "string"
+}Input schema / properties / project_titleAdded value: +{
+ "description": "Optional. Project or production title. Printed on the agreement.",
+ "type": "string"
+}Input schema / properties / termAdded value: +{
+ "description": "For other uses: term from get_license_options.",
+ "type": "string"
+}Input schema / properties / territoryAdded value: +{
+ "description": "For other uses: territory from get_license_options.",
+ "type": "string"
+}Input schema / properties / usageAdded value: +{
+ "description": "Optional. Short description of how the music will be used.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "track_id",
- "license_type",
- "paying_wallet"
-]New value: +[
+ "track_id",
+ "paying_wallet"
+]verify_license1 field changedInput schema / properties / payment_id / descriptionPrevious value: -"The payment_id returned by initiate_license."New value: +"The payment_id returned by initiate_license, for example \"OCM-Q000123\"."calculate_cowriter_splitcalculate_producer_pointscalculate_royalty_splitcalculate_songwriter_publisher_splitcalculate_sync_fee_splitestimate_streaming_royaltiesget_track2 fields changedInput schema / properties / track_id / descriptionPrevious value: -"The track ID returned from search_catalog or ai_search results."New value: +"The track id exactly as returned by search_catalog or ai_search, for example \"417\" or \"partner_82\". Never remove the \"partner_\" prefix."Input schema / properties / track_id / typePrevious value: -"integer"New value: +"string"ai_search1 field changedInput schema / properties / phrase / descriptionPrevious value: -"Plain English music description. Examples: \"I need an upbeat indie rock track for a TV commercial\", \"dark ambient music for a horror game\", \"romantic acoustic guitar for a wedding video\"."New value: +"The user's request, passed through as close to verbatim as possible. Do not rephrase, expand, or add descriptive words, moods, or synonyms the user did not say; extra words narrow the results. Example: if the user says \"I need light pop instrumental songs for a radio ad\", send exactly that."initiate_license2 fields changedInput schema / properties / track_id / descriptionPrevious value: -"The track ID from search_catalog, ai_search, or get_track."New value: +"The track id exactly as returned by search_catalog, ai_search, or get_track, for example \"417\" or \"partner_82\". Never remove the \"partner_\" prefix."Input schema / properties / track_id / typePrevious value: -"integer"New value: +"string"ai_search2 fields changedInput schema / properties / per_pageRemoved value: -{
- "default": 10,
- "description": "Number of results to return. Default 10, maximum 50.",
- "maximum": 50,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / phrase / descriptionPrevious value: -"Plain English music description. Be as descriptive as you like. Examples: \"I need an upbeat indie rock track for a TV commercial\", \"dark ambient music for a horror game\", \"romantic acoustic guitar for a wedding video\"."New value: +"Plain English music description. Examples: \"I need an upbeat indie rock track for a TV commercial\", \"dark ambient music for a horror game\", \"romantic acoustic guitar for a wedding video\"."search_catalog2 fields changedInput schema / properties / page / descriptionPrevious value: -"Page number for pagination. Vary this for different results."New value: +"Page number. Use 2, 3, and so on when the user asks for more tracks."Input schema / properties / per_pageRemoved value: -{
- "default": 20,
- "description": "Results per page. Default 20, maximum 50.",
- "maximum": 50,
- "minimum": 1,
- "type": "integer"
-}initiate_licenseverify_license
Add one secure layer between your agents and this server.