Search 18,594 production-music cues by mood, sound and exact runtime. Instant preview links.
Scored across 8 tools
Most tools have distinct purposes: search, details, versions, duration matching, similar finder, licensing info, and feedback. However, stye_get_track and stye_list_versions overlap—get_track already includes every version, so an agent might select the wrong one. Descriptions are long and clear enough to mostly disambiguate, but the redundancy is a minor flaw.
All tools share the 'stye_' prefix and most follow a verb_noun pattern (search_tracks, get_track, find_similar, fit_to_duration). However, stye_about, stye_cue_sheet, and stye_feedback are noun-only or noun_noun, deviating from the dominant pattern. The naming is still readable and predictable overall.
With 8 tools, the set is well-scoped for a music catalogue: it covers search, detailed lookup, version listing, duration matching, similarity, licensing, and feedback. Each tool has a clear role, and the count sits comfortably in the ideal range.
The surface covers the full lifecycle of browsing a catalogue: discovering via search, examining a cue in depth, exploring versions, finding similar items, matching durations, and obtaining clearance data. There are no obvious dead ends; any missing functionality (e.g., listing all albums) is accessible through search with appropriate filters.
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 happens at licensing.songstoyoureyes.com, 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds critical operational behavior: missing fields are reported as 'not on file' and never filled from any other source, and the user is pointed to the correct contact for gaps. It also clarifies licensing happens elsewhere, which frames the tool's boundary. This goes meaningfully beyond the annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, starting with the resource and content, then adding presentation format and error handling. Each sentence serves a purpose—the missing-field policy and the licensing note are unnecessary. It is not wordy, and every sentence contributes to correct invocation and proper outcome.
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 a very simple tool with one parameter and no output schema, the description adequately covers the essential context: what data is returned, how missing data is reported, and what the user should do next. It does not explain return structure in detail, but no output schema is present, and the tool is straightforward. The description compensates for the lack of an output schema by enumerating the fields conceptually.
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 has full description coverage for the single parameter 'ref' (a track ref from any other tool's results), so the parameter is already fully documented. The description adds no new parameter-specific semantics; it only implies the ref identifies a track/cue. Baseline of 3 is appropriate given the 100% schema_description_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 clearly identifies the resource: clearance data for a cue, specifying writers, publishers, shares, ISRC, and album. It uses the verb 'present' and is distinct from siblings like stye_get_track or stye_search_tracks by focusing on the filing artifact. It lacks an explicit verb like 'retrieve' or 'generate,' but the title and content make the purpose unambiguous.
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 states the intended users (broadcasters or PRO filing) and the need (clearance data), and it implies when it should be used versus doing something else—notably licensing. It does not explicitly name sibling tools or contrast when to use this versus stye_get_track or stye_list_versions. The boundary 'not for licensing' is the only exclusion; there is no broader when-to-use guidance.
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 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. | |
| 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?
Annotations already cover the read-only, idempotent, non-destructive safety profile. On top of that, the description adds substantial behavioral context: result categories ('fit='native'' vs 'fit='cutdown''), the meaning and sign of delta_s, the distinction between licence_ref and ref, and the unconditional requirement to surface listen_url. This goes well beyond what structured fields already express.
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 compact despite covering purpose, result semantics, a mandate for the user-facing URL, and usage triggers. Every sentence carries substance: two result kinds, delta_s explanation, licence_ref/ref distinction, and the listen_url instruction. It is long enough to be useful and short enough to remain scannable, with the core purpose front-loaded.
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 that the tool has no output schema, the description does the necessary duty of explaining return semantics: native vs cutdown results, delta_s, licence_ref vs ref, and listen_url. It also tells the agent how to handle the results (always pass along listen_url). 'The rest of the param', filtering, and limits are already covered by the schema, so the description plus schema together form a complete picture.
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 eight parameters with 88% description coverage, which is above the 80% baseline, so the schema does the heavy lifting. The tool description adds no new parameter semantics to the schema beyond the operational intent (exact runtime fill) and result-level concepts like delta_s, which are not input parameters. The description thus meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Find music that fits an exact runtime' — a specific verb, resource, and constraint — and immediately grounds it with concrete examples ('30-second advert', '90-second title sequence'). This clearly distinguishes the tool from siblings like stye_search_tracks and stye_find_similar, which serve more general discovery use cases.
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 clear context: use it when the user has a cut of known length and needs music to fill it. It also offers broad trigger phrases ('music', 'soundtrack', 'background music', 'Songs To Your Eyes'). However, it does not explicitly say when NOT to use it or direct the agent to a more general sibling such as stye_search_tracks when no runtime is specified, so the exclusion criteria are missing.
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 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 indicate read-only, non-destructive, and idempotent behavior, so the safety profile is covered. The description adds the crucial behavioral note that every result carries listen_url and instructs the agent to always give it to the user, which is extra value beyond 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 moderately long but front-loaded with the core value proposition ('Everything about one cue'), followed by usage context and a critical instruction about listen_url. It is structured in short paragraphs, each with a distinct purpose, and could be slightly trimmed but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a comprehensive overview of what is included in the output (versions, listen_url) and does not rely on an output schema (none exists). It covers the essential need for the agent to know what to return to the user. Minor missing details like the exact structure of the response are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter 'ref' is described as 'a track ref from any other tool's results.' The description does not add any further details about the parameter format or source, but since the schema is fully descriptive, 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 states the tool's purpose: to get full details for one track, including its sound, tempo, key, length, instrumentation, and all versions. It distinguishes itself from siblings by focusing on a single track's comprehensive details, while siblings like search_tracks list tracks and list_versions focus on versions.
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 explicitly says when to use this tool: when someone has picked a track from a search and wants to know more, or wants to know what versions are available. It implies alternatives exist (search_tracks for finding tracks, list_versions for version details) but does not name them, which is acceptable given the clear context.
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 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.
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 ~42,000 stem
versions and ~2,700 drums-only stems, reachable per
track via stye_list_versions; ~975 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,000 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.
Audio may carry a spoken "STYE Music" watermark. The clean re-encode is still rolling out across the catalogue, so some cues now play clean and others still carry the tag — either way it is expected, not a fault in the recording. Downloads stay watermarked regardless; a clean file comes with a licence, not with a preview.
| 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,000 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral context beyond annotations: no pagination (one search returns one full page), repeating a search returns the SAME cues, filters are hard constraints combined with AND, cues missing a tag are silently dropped, has_vocals=true means sung lead vocals while wordless vocal textures count as instrumental, event tags are sparse (only 20 cues carry 'Burning Man'), absent fields mean no data not a fault, audio may carry a watermark, preview links expire in 15 minutes. This is rich behavioral disclosure that goes far beyond what annotations provide.
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 extremely long — roughly 1,500+ words. While every section carries useful information, the sheer length makes it hard for an agent to parse quickly. The structure is well-organized with ALL-CAPS section headers (VOCALS, COMPOSER, EXPLORING, PLACES, ALBUMS, EVENTS AND OCCASIONS, CONTEXTS, REFERENCES AND COMPS, NEGATIVES, STEMS, CLEAN LYRICS), which helps navigation. However, some sections are verbose: the listen_url presentation advice about '<br>' rendering is a client-specific presentation habit that could be shorter, and the watermark explanation is detailed. The front-loading is good (purpose and basic usage first), but the density pushes it toward over-specification. It earns a 3 because it's well-structured but not concise.
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 19-parameter tool with no output schema, the description is remarkably complete. It covers: how to construct a brief, filter semantics (AND, hard constraints, silent drops), the has_vocals trap, composer search, album usage and its anti-pattern, event tag sparsity, context parameter behavior, reference translation (Philip Glass, Reznor x M83, Stranger Things), negative exclusions, stems/cutdowns/keys availability, clean lyrics handling, lyric search limitations, result field semantics (including absent field meaning), listen_url usage, and watermark expectations. The only minor gap is that it doesn't enumerate every possible context name, but it explicitly says unknown names return the full list, so the agent never needs to guess. This is 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 baseline is 3. The description adds significant meaning beyond the schema: it explains the brief should contain vocal TEXTURE (wordless backing vocals) while has_vocals=false handles the lyrics question; it explains the exclude parameter should only contain tag-shaped terms and that prose negation doesn't subtract; it explains the context parameter's ambiguous behavior and country-name generalization; it explains the album parameter disables the per-album cap. The description also adds guidance on limit (set high on first call, no pagination) and max_per_album (defaults to 2, ignored when filtering by album/composer). This goes well beyond the schema's own descriptions, though the schema already covers the basics.
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 this from siblings like stye_find_similar (find similar to a known cue) and stye_list_versions (list versions of a track). The title 'Find music for a scene or brief' reinforces the purpose. The description also explicitly states what makes this tool unique: searching by MEANING against editorial descriptions, not just tags.
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 is exemplary in usage guidance. It says 'USE THIS TOOL whenever someone asks for music, a soundtrack, a score, a cue, background music...' and explicitly contrasts with siblings: stye_find_similar for similar tracks, stye_list_versions for stems/cutdowns, stye_fit_to_duration for duration matching. It gives detailed when-to-use guidance for composer filter, album filter, context parameter, and when NOT to use it (e.g., 'It is NOT how to answer a brief' for album filter). It even explains when to ask the user for direction before searching.
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_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."stye_search_tracks2 fields changedInput schema / properties / excludeAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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.",
+ "title": "Exclude"
+}Input schema / properties / keyAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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.",
+ "title": "Key"
+}stye_search_tracks1 field changedInput schema / properties / contextAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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.",
+ "title": "Context"
+}stye_search_tracks1 field changedInput schema / properties / max_per_albumAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 10,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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.",
+ "title": "Max Per Album"
+}stye_search_tracks1 field changedInput schema / properties / albumAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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.",
+ "title": "Album"
+}stye_fit_to_duration1 field changedInput schema / properties / composerAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only tracks credited to this composer/artist; partial names match, case-insensitive.",
+ "title": "Composer"
+}stye_search_tracks1 field changedInput schema / properties / composerAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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.",
+ "title": "Composer"
+}Human-made production music for sync — search by brief or reference, preview, score to picture.
Search & license real-orchestra music from your agent: EUR 29.90 one-time, WAV + certificate.
Free, copyright-safe AI music library for video creators and AI agents.
Search royalty-free BGM and sound effects (commercial use OK, no credit) and game fan arrangements.
