Search 18,594 production-music cues by mood, sound and exact runtime. Instant preview links.
Scored across 8 tools
Most tools have clearly distinct jobs: about, cue_sheet, feedback, search_tracks, find_similar, and fit_to_duration are separable. However, stye_get_track explicitly promises 'every version that exists of it (stems, shorter cuts, alternate mixes)' which directly overlaps with stye_list_versions, and fit_to_duration also surfaces cutdowns, creating a version-retrieval cluster an agent could misselect among.
All eight tools share a consistent stye_ prefix and snake_case, which makes them predictable as a family. The only deviation is that some are verb_noun (get_track, list_versions, search_tracks, find_similar) while others are bare nouns (about, cue_sheet, feedback), a minor inconsistency.
Eight tools is well-scoped for a music catalogue covering discovery, detail, versions, clearance and feedback. Each tool earns its place and nothing feels redundant or thin.
The surface covers the full lifecycle: search by brief, explore similar, fit to runtime, inspect a cue, list deliverable versions, pull clearance data, read licensing terms and give feedback. Minor gap: album/context browsing is only reachable as search filters, with no dedicated listing operation, but this is workable.
What this service is, how licensing works and what the server sees. Quote the licensing and privacy statements as returned — never paraphrase terms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds a meaningful behavioral requirement: the agent must quote licensing and privacy statements exactly as returned and never paraphrase them. This goes beyond the annotation coverage, though it does not describe response formatting 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 with no filler. It front-loads the tool's purpose and then provides the critical behavioral instruction about quoting. Every sentence adds necessary 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 parameterless informational tool with strong annotations, this description is nearly complete. It tells the agent what topics the output covers and how to handle the returned statements. Without an output schema, it could specify the response structure slightly more, but the current level is sufficient 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?
The tool has zero parameters, so there is no parameter semantics to explain. Schema description coverage is 100% because the properties object is empty. The description appropriately avoids inventing parameter-related content.
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 explicitly identifies what the tool returns: what the service is, how licensing works, and what the server sees. This clearly distinguishes it from the sibling tools, which handle tracks, searches, cues, and feedback.
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 use context is clear: this is the tool for service-level licensing, privacy, and about information. It does not explicitly name alternatives or state when not to use it, but the scope is obvious relative to the siblings. The added instruction to quote statements rather than paraphrase further guides agent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The clearance data a broadcaster or PRO filing needs for one cue: every credited writer with role, society and IPI, every publisher with its share, the ISRC and the album. Present it as a clean table. If a field is not returned, report it as not on file — never fill it from anywhere else — and point the user at info@songstoyoureyes.com for gaps. Licensing itself is arranged with the Songs To Your Eyes team, not in this conversation.
| 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuine behavioral rules beyond them: format the result as a clean table, report missing fields as 'not on file' rather than backfilling, and route gaps to info@songstoyoureyes.com. These are operational constraints an agent would otherwise not know.
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 sentences, front-loaded with what is returned, then the presentation and data-integrity rules, then the licensing boundary. Every sentence carries information, though the escalation/contact detail makes it slightly longer than strictly necessary.
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 must convey the return contents — and it does, field by field, plus formatting guidance for the response. Nothing an agent needs to call and use this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'ref' parameter is documented in the schema as 'A track ref from any other tool's results.' The description adds nothing about the ref parameter, so the schema does all the work; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (clearance/cue sheet data for one cue) and enumerates the returned fields: credited writers with role, society and IPI, publisher shares, ISRC, album. An agent can distinguish this from stye_get_track or stye_search_tracks from the text alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the use case up front ('the clearance data a broadcaster or PRO filing needs') and supplies a boundary — licensing is handled by the Songs To Your Eyes team, not this tool. It does not explicitly name a sibling alternative, but the context for when to reach for this tool is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the catalogue team feedback on how well results fit — a wrong-feeling page, a brief that found nothing, or praise worth keeping. ONLY send it with the user's explicit consent: ask first, and pass consented=true only after they agree. The message should be the user's own words.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | The track ref it concerns, if one. | |
| kind | No | 'search_quality', 'missing_music', 'praise' or 'other'. | other |
| brief | No | The search brief it concerns, if one. | |
| message | Yes | The user's feedback, verbatim. | |
| consented | Yes | True ONLY if the user explicitly agreed to send this feedback. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses that the tool sends data to the catalogue team, a mutation. It adds a key behavioral requirement beyond annotations: the message must be the user's own words (implicitly discouraged from paraphrasing or editing). This is useful guardrail behavior that isn't captured in the annotations, which are sparse (readOnly=false, destructive=false).
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 no filler. First sentence tells what the tool does, second adds the most important usage constraint (consent), third clarifies the content requirement. It is front-loaded with purpose and ends with a crisp rule. Someone could trim little, but it earns each word.
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 feedback tool with full parameter descriptions and no complex output, the description provides enough context: it states the audience, the allowed feedback types, the consent guardrail, and verbatim content rule. It doesn't explain what happens after sending (e.g., acknowledgment) but that's not necessary for agent invocation. It covers the necessary parts.
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 all parameters are already documented. The description adds value by linking the conceptual 'feedback content' to message and kind, using examples (wrong-feeling-ish, missing brief, praise). However, it doesn't add new semantics beyond what the schema already provides for ref, brief, or kind. Meets the baseline for a fully described 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 starts with a clear verb and resource ('Send the catalogue team feedback') and gives concrete examples of what feedback looks like (wrong-feeling page, brief that found nothing, praise). This distinguishes it cleanly from sibling tools like stye_search_tracks or stye_get_track, making the purpose immediately obvious.
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 strong context for when to use the tool: any time results feel wrong or a brief found nothing. It also states a critical when-not condition: only send with explicit user consent, and only after asking first. While it doesn't name alternative tools, none exist for this function; the consent rule acts as an explicit exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cues close in character to a given one — matched on the catalogue's own editorial description of each cue together with its genres, moods and instrumentation — for 'more like this one' moments. It compares how the cues are DESCRIBED, not the waveforms, so it is strong on character and mood and will not hear two cues as alike purely because they sound alike. Give the user each result's listen_url. Results are main mixes from other cue families, at most three per album.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The track ref to match against. | |
| limit | No | How many similar cues to return (default 8). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, and the description adds genuine behavioral detail: it compares textual descriptions rather than waveforms, results are main mixes from other families, and at most three per album. It also tells the agent to expose listen_url to the user.
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 focused sentences with no filler. Key behavioral constraints and output advice are front-loaded, and the styling ('DESCRIBED') make the central point memorable. It could drop a dependent clause, but it earns its length.
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 2-parameter tool with no output schema, the description covers the main behavior, the result content (listen_url), and a per-album constraint. Edge-case details like ordering or result count when the ref is not found are not covered, but the information is sufficient for an agent to call it well.
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 alone provides full descriptions for both parameters (`ref` and `limit` with min/default/max). The description adds no parameter-specific semantics beyond what the schema already states, so the schema-coverage baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — finding cues 'close in character' to a given one — and explains the matching basis (editorial description, genres, moods, instrumentation) and the intended use case ('more like this one' moments). This clearly differentiates it from siblings like stye_get_track or stye_search_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It identifies the natural use case ('more like this one' moments), but does not explicitly compare against alternatives such as stye_search_tracks or say when not to use it. The guidance is implied rather than directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find 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 when someone needs music to license for a video, film, advert, trailer or podcast, 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. | |
| composer | No | Only tracks credited to this composer/artist; partial names match, case-insensitive. | |
| 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?
With annotations already covering the safety profile (readOnly, idempotent, non-destructive), the description adds substantial behavioral context: two result classes with their fit values, the meaning and sign convention of delta_s, the licence_ref vs ref distinction between a cutdown edit and its original, and the guarantee that every result carries a permanent listen_url. These are exactly the traits an agent cannot infer from structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then result semantics, then the listen_url imperative and usage trigger. Every paragraph contributes, though the callout-style line breaks and the listen_url emphasis make it slightly longer than strictly needed.
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 eight parameters, no output schema, and a non-obvious two-kind result model, the description carries the return-value burden and does so thoroughly — explaining fit types, delta_s, licence_ref vs ref, and listen_url. An agent has everything needed to call the tool and interpret its results.
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 88%, so the schema already documents most parameters, including the useful has_vocals clarification. The description adds a little meaning for target_seconds ('for a cut of known length') but mostly restates it; the fit/delta_s discussion concerns output rather than input. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('find music that fits an exact runtime') and immediately anchors it with concrete scenarios (30-second advert, 90-second title sequence). It is clearly distinguishable from siblings like stye_search_tracks or stye_find_similar, which do not fit by duration.
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 final sentence gives explicit usage context: 'when someone needs music to license for a video, film, advert, trailer or podcast, or mentions Songs To Your Eyes.' It also frames the native-vs-cutdown choice ('usually the better choice'), which is practical guidance. It does not explicitly name when to prefer a sibling tool instead, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything 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 when someone needs music to license for a video, film, advert, trailer or podcast, 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 cover read-only, idempotent and non-destructive behaviour, so the description adds real value by disclosing that every result carries a permanent listen_url page and that the agent should always surface it. It says nothing about error cases (e.g. invalid ref) or result size, but the output-shaping instruction is genuinely useful.
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 core first sentence is well front-loaded, but the piece is padded by two separate 'Use this when' clauses whose content overlaps, and by an emphatic listen_url paragraph. Every element is not earning its place; tightening would improve it.
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 one simple parameter, no output schema, and annotation coverage for safety, the description does the necessary work by enumerating what the response contains and highlighting listen_url. The only shortfall is the lack of guidance on failure behaviour and on when to prefer stye_list_versions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and schema description coverage is 100% — the schema already states 'A track ref from any other tool's results.' The description adds no format, range, or sourcing 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 and resource ('Everything about one cue') and enumerates the returned facets: sonic character, tempo, key, length, instrumentation, versions, and a listen link. It does not explicitly say how it differs from the sibling stye_list_versions, even though it claims to return every version that exists, which creates mild overlap.
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?
'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' gives a concrete triggering context. There are no when-not conditions or named alternatives, and the trailing 'or mentions Songs To Your Eyes' reads as a domain-level trigger rather than tool selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show 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 carry the safety profile (readOnlyHint, idempotentHint, destructiveHint), and the description builds on that by explaining what the operation returns beyond the full mix: timed cutdowns, alternate mixes, and stems. It also notes via the parameter description that the whole family is returned, adding useful behavioral context.
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 a bit longer than strictly necessary, but every sentence earns its place: the opening states the purpose, the middle gives concrete examples, and the closing offers a practical when-to-use note. It is front-loaded and readable without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description is essentially complete. It explains the returned family, variants typical to the domain, and the intended use case. Nothing critical gaps appear for an agent to call 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 100%, and the ref parameter is already well-documented in the schema: "any track ref — main mix or one of its versions; the whole family is returned." The tool description adds no additional parameter-specific meaning, so it aligns with the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Show every form a cue can be delivered in," followed by concrete examples (cutdowns, alternate mixes, stems). It is clearly distinct from siblings like stye_get_track or stye_search_tracks, but it does not explicitly differentiate itself from stye_fit_to_duration, which could also address shorter cues.
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 usage context: "Useful when a cue is nearly right but needs to be shorter, quieter under a voice, or stripped back." This tells the agent when to use the tool, but it doesn't mention alternatives or when not to use it, especially compared to stye_fit_to_duration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find music for a video, film, advert, trailer or podcast by describing what it needs to do.
Search 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 when someone needs music to license for a video, film, advert, trailer or podcast (a soundtrack, score, cue or background music to play under footage), or mentions 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.
ONE SEARCH RETURNS ONE FULL PAGE — there is no pagination. Repeating a search with the
same arguments returns the SAME cues, so never search again just to get more of the
same: set limit high enough on the first call (default 15, up to 25). One
well-chosen page usually holds enough range to answer; a second search earns its cost
only when it takes a genuinely different angle or a changed brief.
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 and NAME THE TEXTURE IN THE BRIEF — "background vocals", "choir", "vocal hooks", "group singing" in the brief text are detected server-side and applied as a hard requirement, so every result really carries that texture. Do not re-search if the page is short: a short page means the catalogue's honest supply of that texture.
COMPOSER — when someone asks for music BY a composer or artist ("tracks by Yair Albeg
Wein", "more from this composer"), use the composer filter with the name — partial
names match. It works with no brief at all (a straight listing of that composer's cues)
or combined with a brief to search within their catalogue. Every result carries its
composer credit, so attribution comes from the catalogue itself — never guess it from
outside sources.
EXPLORING, not just matching — for a scene, a place, or any creative request, ONE
search is not an exploration of the whole catalogue. Run SEVERAL searches from
genuinely different angles and curate across them: (1) the literal angle — traditional
instruments and idiom; (2) the FEEL angle — texture, pulse and atmosphere with no
instrument names ("hazy hypnotic modal groove, dusty and sun-baked"); (3) a crossover
angle — the setting's colour through another genre (desert funk, ethnic electronica,
psychedelic world). The feel and crossover angles routinely find the most artistic
picks that the literal angle misses. Raise limit toward 25 when exploring.
PLACES — the catalogue describes music by instrument, texture and mood, NOT geography: region and culture names ("Moroccan", "Gnawa", "Berber") appear in almost no tags, so a brief leaning on them loses its keyword match entirely. Translate the place into what it SOUNDS like — instruments (oud, darbuka, qanun, hand percussion), textures (desert, hypnotic, modal, dusty), and let one of your angles drop the geography altogether.
ALBUMS are curated sets of about five cues built around one idea. The album filter pulls
the rest of a set, and that is the right move when the user NAMES an album, asks what else
is on the one a cue came from, or wants more of a sound they have already picked.
It is NOT how to answer a brief. Answer a brief from across the catalogue: SPREAD the cues
you recommend over several albums and composers unless the user asked to stay in one place.
Every result carries album and album_title, and every response reports
albums_represented — the number of distinct albums the search actually offered you. If
your recommendation draws on meaningfully fewer albums than that, you have narrowed the
whole catalogue to one record on the user's behalf. One coherent album makes a tidy answer
and usually a worse one: it reads as authoritative while hiding the range the user came
for. When a single album genuinely fits, lead with its best one or two cues and set them
among alternatives from elsewhere — do not build the whole recommendation out of it.
EVENTS AND OCCASIONS — a trap worth knowing. Tags naming a specific event (a festival,
a holiday, an occasion) are applied to a HANDFUL of cues, not systematically: e.g. only
20 cues carry "Burning Man" while the catalogue holds ~1,900 electronic cues, and 39 carry "Festival". (Those two tag counts are
literals and were re-checked on 2026-09-04; the electronic figure is read from the
catalogue.) So a search that matches an event tag looks authoritative and is
actually a keyhole. NEVER stop there. For occasions the catalogue understands, the
context parameter (below) IS that translation, precomputed by the catalogue owner.
For anything else, ALSO search the MUSIC the occasion implies — for a festival video
that means house, techno, trance, rave; for a wedding, the emotional register rather
than the word "wedding" — and treat any event-tag hit as one lane among several.
CONTEXTS — owner-curated occasion searches. The context parameter takes a named
context (e.g. 'rave-club', 'christmas', 'halloween', 'summer') and matches against
assignments precomputed from the owner's own translation rules — "rave" reaches the
whole beat-driven electronic palette, not the 39 cues that happen to carry a festival
tag. Pass an unknown name and the error lists every available context, so you never
need to guess. Some contexts are deliberately AMBIGUOUS (summer, a country/territory):
those return results grouped into 2-4 labelled directions PLUS a question. Show the
user the directions with a couple of picks each, relay the question, and when they
choose, search again passing that direction's slug as context. Country names
(Lebanon, Morocco, Turkey...) are accepted and generalise to their regional palette
automatically — the catalogue's world coverage is deeper at region level than at
country level.
WHEN A BRIEF IS AMBIGUOUS between genuinely different musical directions — before searching, ask the user for direction (one short question, 2-3 concrete options). "Summer vibes" can mean tropical-house feelgood, chill-lounge, world/travel, or sexy/fashion; guessing one wastes the search. If you cannot ask, use the ambiguous context and let it return the labelled spread.
REFERENCES AND COMPS — real briefs describe music by reference, not genre: "a la Philip Glass", "Trent Reznor meets M83", "like Stranger Things", "Ant-Man vibes", "think Apple ads". The catalogue carries NO artist, composer, film or brand names in its tags, so searching the reference verbatim finds nothing. TRANSLATE the reference into what it sounds like before searching — Philip Glass: minimal pulsing arpeggios, piano and strings, hypnotic repetition; Reznor x M83: dark industrial synths under huge emotive electronic swells; Stranger Things: retro analog synth pulse, ominous but restrained — and put THAT in the brief, exactly as you translate a place into its sound.
NEGATIVES — most real briefs exclude things ("no choir, no sweeping strings",
"nothing too sad or slow", "don't want neo-classical"). Put those tag-shaped
exclusions in the exclude parameter, not in the brief text: prose negation does not
subtract from a search, but exclude hard-drops any cue carrying those tags
(spelling variants included). Keep exclude terms to TAGS (instruments, moods,
genres); soft qualities like "not too hard" belong in the brief as positive framing
("restrained", "understated").
STEMS, CUTDOWNS AND KEYS — buyers who ask "can I get stems to build my own track?"
can be told yes: the catalogue holds ~43,000 stem
versions and ~2,700 drums-only stems, reachable per
track via stye_list_versions; ~1,000 cues have a
labelled :30 cutdown (stye_fit_to_duration finds natural fits too), and the key filter
matches briefs like "preferably in E" (matches both E and Em;
~7,100 mains carry a key).
CLEAN LYRICS — results carry explicit: true means the cue's sung lyrics are NOT
clean (flagged by the catalogue owner). For "fully clean lyrics only" briefs, drop
any result with explicit=true.
LYRICS ARE SEARCHABLE, BUT BY WORDING, NOT BY THEME — and the distinction matters because the catalogue is overwhelmingly instrumental. 328 cues have lyrics on file, and those lyrics ARE in the full-text index, so a brief containing words that are actually sung will match them. What this path does NOT do is match by lyric SUBJECT: "a song about winning" finds cues whose lyrics contain "winning", not every cue about victory. Put the likely WORDING in the brief, and treat a lyric hit as a bonus on top of the musical match rather than as a filter — 328 of the catalogue is a keyhole, the same trap as an event tag above.
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. ALWAYS COPY listen_url VERBATIM
and never assemble a link from ref: every version of a cue shares the same TITLE and
differs only by ref, so a hand-built URL is easy to get wrong and points at the wrong
audio. Every row that can be played carries its own listen_url — use that one.
PUT IT ON ITS OWN LINE AS PLAIN MARKDOWN, and never wrap it in raw HTML. Observed 2026-09-10 in a portrait Claude window: every link came back preceded by a literal "" — the assistant reaching for an HTML line break, which renders as visible text rather than as a break. The data is clean; this is a presentation habit, and saying so here is the only place it can be corrected for every client at once.
Also returned: title, album, composer (the credited artist — trust THIS field for attribution, never outside sources), description (what it sounds like and what it suits), duration_s, bpm, key, has_vocals, genres, moods, instruments, use_cases, keywords (extra catalogue tags beyond those three lists — tempo bands like 'Mid Tempo', placements like 'TV Score'), 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.
A field that is absent from a row means the catalogue has no data for it — an absent bpm means simply untagged, not slow; an absent composer means no usable credit; an absent cutdown_lengths_s means no timed cutdowns exist. Never treat absence as a fault in the result.
The player streams nearly every cue clean. A file downloaded from it without a licence is a watermarked test file (a spoken "STYE Music" tag), by design — a clean file comes with a licence, not with a preview. preview_url, when requested, is watermarked too.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Musical key, e.g. 'E', 'Em', 'Bb', 'F# minor'. A bare major key also matches its minor ('E' matches E and Em) — briefs saying 'in E' usually accept both. ~7,100 mains carry key data, about 44% of the catalogue; the filter skips the rest, so use it only when the brief asks. | |
| album | No | Only tracks from this album — by name ('Desert Funk') or catalogue code ('STYE1204'); partial names match. Use it whenever someone names an album or asks what else is on the one a track came from. Works with no brief (lists the album) or with one (search inside it). Setting it disables the per-album cap, so the whole set comes back — which is why it is for a user who ASKED about an album, not a way to answer a brief. Answering a brief out of one album narrows the catalogue to one record; spread the picks instead. | |
| 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. One page per search — there is NO pagination, and repeating a search with the same arguments returns the SAME cues. Ask for as many as you need up front rather than searching twice; raise it toward 25 when exploring. | |
| 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. | |
| context | No | Owner-curated occasion/context search — see CONTEXTS in the tool description. A context name ('rave-club', 'christmas', 'halloween', 'summer') or a country name (generalises to its regional palette). Unknown names return the full list of valid contexts. Ambiguous contexts return results grouped into labelled directions plus a question to relay to the user. | |
| exclude | No | Hard-drop any cue carrying ANY of these tags — for a brief's exclusions ('no choir', 'avoid sweeping strings', 'not neo-classical'). Spelling variants and plurals are folded, so 'neo-classical' also drops 'Neoclassical'. Tag-shaped terms only; soft qualities belong in the brief. | |
| composer | No | Only tracks credited to this composer/artist. Partial names match ('Albeg' finds 'Yair Albeg Wein'), case-insensitive. Works alone — 'music by <name>' needs no brief — or combined with a brief to search within one composer's catalogue. Every result carries its `composer` credit either way. | |
| 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. | |
| max_per_album | No | Cap how many cues from any ONE album appear, so results spread across the catalogue instead of returning a block from one record. Defaults to 2 for a general search. Raise it, or set it high, when you deliberately want depth from one album — and it is ignored automatically when you filter by album or composer. | |
| 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?
With annotations already covering read-only/idempotent safety, the description adds rich behavior: filters are hard AND constraints that silently drop untagged cues, one page has no pagination, repeated searches return identical cues, lyric matching is wording-only, previews/downloads are watermarked, and absent fields simply mean untagged data. Nothing contradicts 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 purpose and organized under all-caps headings, making it navigable despite its length. It is unusually long for a tool description and repeats some album/event guidance, but most sentences carry actionable, non-obvious constraints.
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, yet the description explains returned fields (listen_url, composer, description, energy, resolves, vo_friendly, versions, cutdown_lengths_s, ref, preview_url), how to present listen_url, and how to interpret absent fields. Combined with the annotations and full schema coverage, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents each parameter in detail, so baseline is 3. The description still adds meaningful cross-parameter semantics not in the schema: filters combine with AND and can empty results, exclude must be tag-shaped rather than prose negation, and limit must be set high up front because there is no pagination.
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 ('Find music for a video, film, advert, trailer or podcast') and explains that it searches cues by meaning rather than tags. It also names sibling tools for stems and cutdowns (stye_list_versions, stye_fit_to_duration), so an agent can route between search and adjacent operations.
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?
Provides extensive when-to-use guidance and explicit when-not-to-do-X rules: don't re-search for more of the same, don't stack filters, don't use event tags as the only lane, don't search references verbatim, and use context/composer for those cases. It also names alternatives for stems and cutdowns.
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.
stye_search_tracks1 field changedInput schema / properties / key / descriptionPrevious value: -"Musical key, e.g. 'E', 'Em', 'Bb', 'F# minor'. A bare major key also matches its minor ('E' matches E and Em) — briefs saying 'in E' usually accept both. ~7,000 mains carry key data, about 44% of the catalogue; the filter skips the rest, so use it only when the brief asks."New value: +"Musical key, e.g. 'E', 'Em', 'Bb', 'F# minor'. A bare major key also matches its minor ('E' matches E and Em) — briefs saying 'in E' usually accept both. ~7,100 mains carry key data, about 44% of the catalogue; the filter skips the rest, so use it only when the brief asks."stye_search_tracks2 fields changedInput schema / properties / limit / defaultPrevious value: -8New value: +15Input schema / properties / limit / descriptionPrevious value: -"Max results."New value: +"Max results. One page per search — there is NO pagination, and repeating a search with the same arguments returns the SAME cues. Ask for as many as you need up front rather than searching twice; raise it toward 25 when exploring."stye_search_tracks1 field changedInput schema / properties / key / descriptionPrevious value: -"Musical key, e.g. 'E', 'Em', 'Bb', 'F# minor'. A bare major key also matches its minor ('E' matches E and Em) — briefs saying 'in E' usually accept both. About 7,500 mains carry key data; the filter skips the rest, so use only when the brief asks."New value: +"Musical key, e.g. 'E', 'Em', 'Bb', 'F# minor'. A bare major key also matches its minor ('E' matches E and Em) — briefs saying 'in E' usually accept both. ~7,000 mains carry key data, about 44% of the catalogue; the filter skips the rest, so use it only when the brief asks."stye_aboutstye_cue_sheetstye_feedbackstye_find_similarstye_search_tracks1 field changedInput schema / properties / album / descriptionPrevious value: -"Only tracks from this album — by name ('Desert Funk') or catalogue code ('STYE1204'); partial names match. Use it whenever someone names an album or asks what else is on the one a track came from. Works with no brief (lists the album) or with one (search inside it). Albums here are curated sets of ~5 cues around one idea, so pulling the whole album is often the best answer."New value: +"Only tracks from this album — by name ('Desert Funk') or catalogue code ('STYE1204'); partial names match. Use it whenever someone names an album or asks what else is on the one a track came from. Works with no brief (lists the album) or with one (search inside it). Setting it disables the per-album cap, so the whole set comes back — which is why it is for a user who ASKED about an album, not a way to answer a brief. Answering a brief out of one album narrows the catalogue to one record; spread the picks instead."Search 2M+ licensed production-music tracks, find similar ones by track or audio, share pick lists.
Human-made production music for sync — search by brief or reference, preview, score to picture.
Generate, edit and stream royalty-free music, or search a licensed catalogue.
Search & license real-orchestra music from your agent: EUR 29.90 one-time, WAV + certificate.
Add one secure layer between your agents and this server.
