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.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 6 of 6 tools scored.
ai_search and search_catalog both search the OnChain Music catalog using natural language descriptions, making their boundaries unclear despite the descriptions. The other tools (get_track, calculate_royalty_split, get_genre_conventions, get_loudness_standards) are clearly distinct.
Most tools follow a clear verb_noun snake_case pattern (calculate_royalty_split, get_genre_conventions, get_loudness_standards, get_track, search_catalog). ai_search deviates from this pattern by using a noun prefix instead of a verb, but the convention is otherwise consistent.
With 6 tools, the server is well-scoped for its purpose: catalog searching, track retrieval, and music business utilities. Each tool contributes a distinct function without unnecessary bloat.
The tool set covers catalog search, track metadata retrieval, royalty calculation, genre conventions, and loudness standards. A direct licensing/purchase tool is absent, but the search results include a results_url for external licensing, so the core workflow is supported. Minor gaps like listing all genres or artists are easily worked around via search.
ai_searchAInspectSearch the OnChain Music catalog using a plain English description. Send a natural language phrase and the API automatically extracts genre, mood, tempo, and other parameters. Best for open-ended requests like "I need something cinematic and tense for a thriller scene" or "upbeat summer pop for a travel vlog". Returns tracks with metadata and license pricing, plus the translated search parameters for transparency.
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes | 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". | |
| per_page | No | Number of results to return. Default 10, maximum 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently explains the automatic extraction of genre/mood/tempo and states that the response includes metadata, license pricing, and translated search parameters. The verb 'Search' implies a read-only operation. It lacks details on rate limits or auth, but for a search tool this is sufficient, earning a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, followed by usage guidance and output details. Every sentence earns its place, with no fluff or repetition. This is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description correctly includes return behavior ('Returns tracks with metadata and license pricing, plus the translated search parameters'). It also explains the natural language processing capability and gives example queries. Per_page details are in the schema, so the description is complete for a search tool with two parameters and no annotations.
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 input schema already provides descriptive coverage for both parameters (100%). The description adds value by explaining how 'phrase' works through natural language examples and the extraction behavior, but it adds nothing beyond the schema for 'per_page'. The schema does the heavy lifting, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: search the OnChain Music catalog using a plain English description. It also distinguishes itself by emphasizing natural language processing ('the API automatically extracts genre, mood, tempo') and gives concrete examples. However, it does not explicitly contrast with sibling tool 'search_catalog', so it lacks direct sibling differentiation, meriting a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Best for open-ended requests' and provides clear example queries, giving useful context on when to use the tool. It does not explicitly mention when not to use it or name alternatives, but the 'open-ended' qualifier implies a contrast with structured search. This aligns with a 4: clear context, but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_royalty_splitAInspectCalculates royalty splits and estimated earnings for music rights deals. Handles songwriter/publisher splits, producer points, co-writer splits, sync fee splits, and streaming payout estimates. Works for any music — not limited to the OnChain Music catalog. Useful for artists, managers, agents, and label tools that need to model deal economics.
| Name | Required | Description | Default |
|---|---|---|---|
| streams | No | Number of streams. Used for streaming_estimate. | |
| writers | No | Array of co-writers with their percentage splits. Used for co_writer_split. Each item: { name: string, percentage: number }. Percentages must sum to 100. | |
| platform | No | Streaming platform for payout estimate. Use "average" for a blended estimate across platforms. | |
| sync_fee | No | Total sync licensing fee in USD. Used for sync_fee_split. | |
| units_sold | No | Number of units sold. Used for producer_points calculation. | |
| gross_royalties | No | Total gross royalties collected (in USD). Used for songwriter_publisher_split and co_writer_split. | |
| producer_points | No | Number of producer points (percentage of master royalties). Used for producer_points calculation. Example: 3 for 3 points. | |
| calculation_type | Yes | The type of royalty calculation to perform. | |
| artist_royalty_rate | No | Artist royalty rate as a percentage of label revenue (0-100). Used for streaming_estimate. Example: 18 for a standard 18% royalty deal. Use 100 for independent artists keeping all revenue. | |
| master_royalty_rate | No | Master royalty rate as a percentage (0-100). Used for producer_points. Example: 18 for an 18-point deal. | |
| publisher_percentage | No | Publisher's percentage of the songwriter share (0-100). Used for songwriter_publisher_split. Example: 50 for a 50/50 co-publishing deal. | |
| suggested_retail_price | No | Suggested retail price of the album in USD. Used for producer_points calculation. Example: 9.99. | |
| master_owner_percentage | No | Master rights owner's share of the sync fee as a percentage (0-100). Used for sync_fee_split. Typically 50% goes to master, 50% to publishing. | |
| publisher_sync_percentage | No | Publisher's share of the sync fee as a percentage (0-100). Used for sync_fee_split. The remainder goes to the songwriter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It conveys that the tool is a read-only calculator ('Calculates', 'Handles') and discloses that streaming estimates are approximate ('estimated earnings'). It also mentions it works on any music, setting expectations for input scope. While it lacks details on output structure or error conditions, the core non-destructive, estimation-based behavior is clearly communicated.
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 two sentences, front-loaded with the core action ('Calculates') and resource ('royalty splits'), followed by a list of supported types and a concise audience/scope statement. Every sentence serves a purpose, with zero fluff 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?
Given the tool's complexity (14 parameters, 5 calculation types) and the absence of an output schema, the description provides the essential overarching context: what the tool does, who it's for, and that it isn't limited to the OnChain catalog. The rich schema descriptions cover per-parameter details (e.g., 'Used for producer_points calculation'), so the description doesn't need to repeat that. A minor gap is the lack of expected output format, but the description is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds high-level context by listing the calculation types, which maps to the calculation_type enum, but it does not add per-parameter meaning beyond the schema. The schema already thoroughly documents each parameter's purpose and the calculation type it supports.
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 clearly states the tool's function: 'Calculates royalty splits and estimated earnings for music rights deals.' It enumerates specific calculation types (songwriter/publisher splits, producer points, co-writer splits, sync fee splits, streaming payout estimates) and explicitly notes it works for any music, distinguishing it from sibling tools like search or genre conventions.
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 provides clear context for when to use the tool: 'Useful for artists, managers, agents, and label tools that need to model deal economics.' It also clarifies scope ('not limited to the OnChain Music catalog'). However, it does not explicitly name alternatives or state when not to use it, though the sibling tools are clearly unrelated lookup/search functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_genre_conventionsAInspectReturns 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It successfully conveys the scope ('Works for any music — not limited to the OnChain Music catalog') and lists the specific data returned. However, it does not mention edge cases (e.g., unknown genres), rate limits, or response format, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: (1) defines the output, (2) lists use cases, (3) clarifies scope. It is front-loaded with the core behavior and contains no redundant or filler content. 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?
Although there is no output schema, the description provides a clear list of output categories (BPM, song structure, instrumentation, etc.) and use cases. It covers the essential aspects for a simple lookup tool with two parameters. The only minor gap is not explicitly linking the 'include_sync_uses' parameter to the 'common sync use cases' output, but this is easily inferred. Overall, it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully explains both parameters ('genre' and 'include_sync_uses'). The description adds minimal parameter-related meaning beyond the schema—it only implies that 'genre' determines the conventions and that 'sync use cases' are part of the output. Since the schema handles the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns music industry conventions for a given genre including typical BPM ranges, song structure, instrumentation, key tendencies, production characteristics, and common sync use cases.' It uses a specific verb ('Returns') and a distinct resource ('music industry conventions for a given genre'), which clearly distinguishes it from sibling tools like search_catalog or get_track.
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 provides explicit use cases: 'Useful for songwriting, production decisions, A&R research, playlist curation, and sync licensing briefs.' This gives clear context for when to use the tool. However, it does not explicitly mention when not to use it or name alternative tools, 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.
get_loudness_standardsAInspectReturns 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output contents (integrated LUFS target, true peak limit, short-term LUFS), and clarifies scope ('not limited to the OnChain Music catalog'). This goes beyond a simple 'get' and provides a good transparency baseline, though it doesn't describe edge cases or format details.
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 two sentences long, front-loaded with the core purpose, and each sentence earns its place (purpose, then use cases/scope). No filler or 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 simple tool with one optional parameter, no output schema, and good annotations-like context in the description, the description fully covers what an agent needs to know: what the tool returns, why to use it, and that it applies broadly. The context is 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?
The input schema already documents the single platform parameter with examples and a description, achieving 100% coverage. The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: 'Returns the official loudness normalization standards for major music and video platforms.' It names a specific resource (loudness standards) and a specific action (returns), and distinguishes itself from sibling tools like get_genre_conventions and search_catalog, which serve different functions.
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 provides concrete use cases: 'Useful for mastering decisions, mix prep, and ensuring tracks meet platform requirements before distribution or licensing.' It doesn't explicitly state when not to use it or mention alternatives, but the context is clear enough that an agent can infer appropriate usage. This is close to explicit guidance, hence a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trackAInspectRetrieve full metadata for a specific track from the OnChain Music catalog, including license pricing, available download formats (MP3, WAV, AIF), artist information, BPM, key, mood, and complete license terms. Use this after search_catalog or ai_search to get full details before purchasing a license.
| Name | Required | Description | Default |
|---|---|---|---|
| track_id | Yes | The track ID returned from search_catalog or ai_search results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does indicate a read-only retrieval operation via 'Retrieve' and lists the data categories returned, but it omits operational details such as authentication needs, error behavior, or rate limits. Adequate but not rich.
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 concise sentences: the first states the action and scope, the second provides usage context. No filler or redundancy; front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool with no output schema, the description adequately explains what will be returned (metadata categories, license terms) and when to use it. It could mention return structure or error cases, but the given context is sufficient for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes track_id as the ID returned from search_catalog or ai_search, so the description adds little beyond reinforcing that provenance. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('full metadata for a specific track from the OnChain Music catalog'), and enumerates the metadata content. It clearly distinguishes the tool from search_catalog and ai_search by positioning it as the follow-up detail-fetch 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 explicitly states 'Use this after search_catalog or ai_search to get full details before purchasing a license', providing direct when-to-use guidance and naming the alternative discovery tools. This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_catalogAInspectSearch the OnChain Music catalog of 6,000+ independently owned, fully cleared tracks, plus partner catalogs. Filter by genre, mood, tempo, BPM, key, and instrumentation. All results are available for immediate licensing with USDC on Base. Use the description parameter as your primary search field — pass style, mood, energy, and use-case words. Returns track IDs, metadata, license pricing, and a results_url in meta that links to a preview page where users can listen to tracks before licensing.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Musical key. Examples: C Minor, G Maj, A Minor, F Maj. | |
| page | No | Page number for pagination. Vary this for different results. | |
| 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. | |
| per_page | No | Results per page. Default 20, maximum 50. | |
| 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 | Filter by intended license type. social_media = $5 USDC. all_digital = $35 USDC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that results are immediately licensable with USDC on Base, and that the response includes a results_url for previewing tracks. It does not mention rate limits or side effects, but as a read-only search, the description is reasonably transparent. Minor imprecision: 'filter by mood' but no direct mood parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose, then filters, licensing, and return details. Every sentence provides actionable information with no fluff.
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 11 parameters and no output schema, the description covers the tool's scope, filterable attributes, licensing requirement, and return fields including a preview URL. It is complete for a search tool, as pagination details are already in 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?
The input schema already provides detailed descriptions for all 11 parameters (100% coverage), including examples for the 'description' field. The main description adds a highlight about the 'description' field being primary but does not add substantial new semantic meaning 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?
The description uses the specific verb 'Search' with the resource 'OnChain Music catalog', and clearly distinguishes it from sibling tools like get_track by focusing on discovery and licensing. It also lists filter dimensions (genre, BPM, key, etc.).
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 provides clear context for use: finding licensable tracks with USDC, and explicitly directs users to use the 'description' parameter as the primary search field. However, it does not explicitly state when not to use this tool or mention alternatives like ai_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
