Search 18,594 production-music cues by mood, sound and exact runtime. Instant preview links.
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 4 of 4 tools scored. Lowest: 3.6/5.
Each tool has a clear primary purpose: search, inspect, list versions, and fit to duration. However, get_track already 'returns every version that exists' of a cue, which partially overlaps with list_versions, creating potential ambiguity about which to use.
All tools follow a consistent 'stye_' prefix with verb_noun pattern: fit_to_duration, get_track, list_versions, search_tracks. This is perfectly uniform and predictable.
Four tools is well-scoped for a catalogue lookup server: search, detail, versions, and duration-specific search. Each tool earns its place without unnecessary bloat or missing essentials.
The core discovery workflow is covered: search by description, retrieve full details, inspect available versions, and find tracks by exact duration. There is no obvious dead end for typical catalogue use cases.
stye_fit_to_durationFind music that fits a runtimeAFind music that fits an exact runtime — for a cut of known length, like a 30-second advert or a 90-second title sequence.
Two kinds of result come back. Some cues simply run close to the target length already (fit='native'). Others are purpose-made short edits of a longer piece — a 30-second mix cut down by the composer (fit='cutdown') — which is usually the better choice, because it is built to land on time rather than fade out.
delta_s is how far each result sits from the target, negative meaning shorter. For a cutdown, licence_ref identifies that specific edit (the thing to license), while ref points at the full-length original that carries the description and the preview.
Every result carries listen_url — a permanent page where the cue can actually be played. ALWAYS give the user the listen_url. A track they cannot hear is of no use to them.
Use this whenever someone asks for music, a soundtrack, a score, a cue, background music, something to play under footage — or mentions Songs To Your Eyes.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Optional sound brief, e.g. 'epic cinematic trailer'. | |
| limit | No | ||
| moods | No | Match ANY of these moods. | |
| has_vocals | No | true = songs with sung lead vocals/lyrics only. false = everything else, including wordless vocal textures (background vocals, choir) — for 'background vocals' requests use false, not true. | |
| target_seconds | Yes | The runtime to fill, in seconds — e.g. 30 for a 30-second spot. | |
| include_previews | No | Attach streaming preview links (15-min expiry). | |
| tolerance_seconds | No | Acceptable deviation. Default: 15% of target, minimum 2s. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the read-only and idempotent annotations by explaining result types ('native' vs 'cutdown'), the meaning of 'delta_s', the distinction between 'licence_ref' and 'ref', and the critical instruction to always provide 'listen_url'. This adds substantial behavioral context not derivable from annotations alone.
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 moderately long but well-structured into clear paragraphs. Each section adds value: purpose, result types, field semantics, and usage directive. The 'ALWAYS give the user the listen_url' instruction is emphatic and important. It is concise enough for its content, though slightly verbose in the usage guidance section.
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 full burden of explaining return values. It does so thoroughly by detailing the two result types, the meaning of each relevant field, and the practical instruction about listen_url. Given the tool's moderate complexity and rich annotations, the description is comprehensive and complete for an AI agent to use 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 description coverage is high (86%), so the parameters are already well-documented. The description adds context around the target duration concept and explains output fields like 'delta_s', but it does not meaningfully augment the input parameter semantics beyond what the schema provides. Thus, the 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 with a specific verb and resource: 'Find music that fits an exact runtime'. It distinguishes itself from siblings by focusing on duration matching and explicitly mentions the use case for known-length cuts (e.g., 30-second adverts). This is a distinct purpose compared to generic track 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?
The description provides clear when-to-use guidance: 'Use this whenever someone asks for music, a soundtrack, a score, a cue, background music… or mentions Songs To Your Eyes.' It also gives context for the specific scenario of fitting a runtime. However, it does not explicitly state when not to use this tool or name alternative sibling 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.
stye_get_trackGet full details for one trackAEverything about one cue: what it sounds like and suits, its tempo, key, length and instrumentation, every version that exists of it (stems, shorter cuts, alternate mixes), and a link to hear it.
Use this when someone has picked a track from a search and wants to know more, or wants to know what else that cue can be delivered as.
Every result carries listen_url — a permanent page where the cue can actually be played. ALWAYS give the user the listen_url. A track they cannot hear is of no use to them.
Use this whenever someone asks for music, a soundtrack, a score, a cue, background music, something to play under footage — or mentions Songs To Your Eyes.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | A track ref from any other tool's results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: every result includes a permanent 'listen_url' page, and it explicitly instructs the agent to ALWAYS provide this URL to the user because a track they cannot hear is useless. This goes beyond annotations and is useful operational guidance.
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 well-structured with a concise first sentence that defines purpose, followed by clear usage and a prominent listen_url note. However, it becomes repetitive with 'Use this whenever someone asks for music...' which duplicates and contradicts earlier usage guidance, and the overall length is more than needed for a single-parameter read-only tool.
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 low-complexity read tool with strong annotations and full schema coverage, the description covers the essential return content (track attributes, versions, listen_url) and the critical behavioral requirement to always surface the listen_url. The absence of an output schema is compensated by listing the main returned fields. The only notable gap is the misleading usage overgeneralization, which prevents a perfect score.
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 parameter 'ref' is already fully described in the schema as 'A track ref from any other tool's results,' giving 100% schema description coverage. The tool description does not add further parameter-level detail beyond implying the ref comes from a search result. With complete 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 clearly identifies the tool as retrieving comprehensive details for a single track, enumerating the specific data returned (tempo, key, length, instrumentation, versions, listen_url). It distinguishes itself from sibling tools like 'stye_search_tracks' (finding tracks) and 'stye_list_versions' (which focuses on one subset) by framing this as the full-detail aggregation tool.
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 a clear use case: 'when someone has picked a track from a search and wants to know more.' However, it then makes an overbroad and misleading claim: 'Use this whenever someone asks for music, a soundtrack, a score, a cue, background music, something to play under footage — or mentions Songs To Your Eyes.' This contradicts the sibling tool 'stye_search_tracks' which would be the appropriate first step for such broad requests, and fails to mention 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.
stye_list_versionsList versions, stems and shorter cutsAShow every form a cue can be delivered in.
Most cues come with more than the full-length mix: timed cutdowns (15, 30, 60 seconds) built to hit standard ad and promo lengths; alternate mixes such as no-drums, underscore or instrumental, for when music has to sit beneath dialogue; and individual instrument stems for an editor who wants to rebalance the track.
Useful when a cue is nearly right but needs to be shorter, quieter under a voice, or stripped back.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Any track ref — main mix or one of its versions; the whole family is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to cover safety. It adds context about what the tool returns (all version forms) and the rationale behind them. This is useful but not extensive; no mention of output format or potential 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?
The description is front-loaded with a clear one-sentence summary, then expands with concrete examples of version types, and ends with usage guidance. Each paragraph serves a distinct purpose, though it could be slightly more concise; the overall structure is effective.
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 a good job explaining the tool's purpose and when to use it. The parameter is fully documented in the schema, and annotations cover safety. However, it lacks an explicit statement of the output structure, which a tool without an output schema might be expected to provide.
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 covers the single parameter 'ref' with a description: 'Any track ref — main mix or one of its versions; the whole family is returned.' This is 100% coverage, and the tool description adds no additional parameter details, 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 opens with 'Show every form a cue can be delivered in,' which clearly states the verb (show/list) and resource (cue versions). It further elaborates with specific examples (cutdowns, alternate mixes, stems), distinguishing it from sibling tools like search_tracks 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 in the final paragraph: 'Useful when a cue is nearly right but needs to be shorter, quieter under a voice, or stripped back.' It also explains the types of versions available in context. However, it does not explicitly contrast with sibling tools like stye_fit_to_duration, so no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stye_search_tracksFind music for a scene or briefAFind music for a video, film, advert, trailer or podcast by describing what it needs to do.
Search 18,594 professionally produced cues by MEANING, not just tags — describe the scene, the mood, the instruments, how it should develop. "Tense investigative underscore that never resolves" or "warm and hopeful for a charity film" work far better than single keywords, because the brief is matched against editorial descriptions of how each cue actually behaves as well as against its tags.
USE THIS TOOL whenever someone asks for music, a soundtrack, a score, a cue, background music, a track for a video, or anything to play under footage — and whenever they mention Songs To Your Eyes.
Put the sound in brief. Use filters ONLY for requirements the user actually stated:
every filter is a hard constraint, they combine with AND, and cues missing a tag are
silently dropped — so stacking several filters can empty the results. If a search comes
back thin, drop filters and put the nuance in the brief before concluding the catalogue
has nothing.
VOCALS — the trap to avoid: has_vocals=true means SONGS with sung lead vocals and lyrics. Wordless vocal textures (background vocals, oohs and aahs, choir pads) count as INSTRUMENTAL in this catalogue. A user asking for "background vocals" almost always wants NO lyrics: set has_vocals=false, describe the texture in the brief, and optionally add 'Background Vocals' or 'Choir' to the instruments filter.
Each result describes one cue. listen_url is the important one — a permanent page where the track can be played, with cover art and a waveform. Give it to the user every time; it is how they actually hear the music.
Also returned: title, album, description (what it sounds like and what it suits), duration_s, bpm (null means simply untagged, not slow), key, has_vocals, genres, moods, instruments, use_cases, and three editorial judgements worth quoting back — energy (low | low-building | moderate | building | high), resolves (does it land, or stay unresolved and tense), and vo_friendly (does it leave space for a voiceover). versions counts the stems, alternate mixes and shorter cuts that exist for it, and cutdown_lengths_s lists those cut lengths in seconds. ref identifies the cue for the other tools. preview_url, when present, is a temporary streaming link that expires after 15 minutes — prefer listen_url, which never expires.
All audio is a watermarked evaluation copy: you will hear a spoken "STYE Music" tag over it. That is expected, not a fault in the recording.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | What the music should sound like and what it is for — the mood, the scene, the instruments, vocal textures, how it should build. E.g. 'tense investigative underscore that never resolves'. Tempo and length belong in the filters below; vocal TEXTURE (wordless backing vocals, choir pads) belongs HERE, in the brief. | |
| limit | No | Max results. | |
| moods | No | Match ANY of these moods, e.g. ['Tension','Mysterious']. | |
| energy | No | One of: low, low-building, moderate, building, high. | |
| genres | No | Match ANY of these genres, e.g. ['Trailer','Orchestral']. | |
| bpm_max | No | Maximum BPM. | |
| bpm_min | No | Minimum BPM. Use sparingly: around 54% of the catalogue has no tempo tag, and any BPM filter excludes all of those cues — good matches included. Prefer describing the pace in the brief. | |
| has_vocals | No | true = SONGS with sung lead vocals and lyrics. false = everything else, INCLUDING cues with wordless vocal textures (background vocals, oohs/aahs, choir pads) — those count as instrumental here. 'Background vocals' in a request almost always means NO lyrics: use false and put the texture in the brief. Omit = both. | |
| instruments | No | Match ANY of these instruments, e.g. ['Piano','Strings']. | |
| vo_friendly | No | true = only tracks that leave space for voiceover. | |
| duration_max_s | No | Maximum runtime in seconds. | |
| duration_min_s | No | Minimum runtime in seconds. | |
| include_previews | No | Attach a streaming preview link to each result (slower; links expire in 15 minutes). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) establish the operation is safe, and the description reinforces this without contradiction. It goes far beyond annotations by disclosing important behaviors: 'All audio is a watermarked evaluation copy... That is expected,' 'preview_url... expires after 15 minutes,' 'bpm (null means simply untagged, not slow),' and the fact that filters 'combine with AND' and 'cues missing a tag are silently dropped.' This gives the agent a realistic model of how the tool behaves.
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 long but well-structured: it opens with a clear one-sentence purpose, then uses paragraph breaks and bolded headers (VOCALS, filters, watermark) to organize information. Every sentence adds value, though some repetition occurs (e.g., 'background vocals' appears in multiple sections). For a tool with 13 parameters and a rich result set, the length is justified and the front-loaded purpose makes it easy to consume.
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 absence of an output schema, the description fully explains all return fields: 'listen_url is the important one,' plus title, album, description, duration_s, bpm, key, has_vocals, genres, moods, instruments, use_cases, energy, resolves, vo_friendly, versions, cutdown_lengths_s, ref, and preview_url. It also clarifies the meaning of null values and how to interpret editorial judgements. The tool's complexity is fully addressed, making the description self-sufficient.
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?
While the schema already covers 100% of parameters, the description adds critical operational context that the bare schemas don't convey. For example, it explains the 'has_vocals' trap: 'true = SONGS with sung lead vocals and lyrics... Wordless vocal textures count as INSTRUMENTAL.' It also warns that BPM filters are lossy because 'around 54% of the catalogue has no tempo tag,' and clarifies that 'every filter is a hard constraint... stacking several filters can empty the results.' This goes well beyond the schema's basic descriptions.
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 and resource: 'Find music for a video, film, advert, trailer or podcast by describing what it needs to do.' It clearly distinguishes itself from siblings by emphasizing search by 'MEANING' and explicitly states 'USE THIS TOOL whenever someone asks for music, a soundtrack, a score, a cue, background music, a track for a video, or anything to play under footage.' This is a precise, action-oriented purpose that leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (any music request) and integrates alternative tool usage by noting 'ref identifies the cue for the other tools.' It also offers tactical advice: 'Use filters ONLY for requirements the user actually stated,' warns about filter stacking, and instructs to 'drop filters and put the nuance in the brief' when results are thin. The vocal trap section further clarifies when to set has_vocals=false versus true, which prevents common misuse.
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!
