Search 18,594 production-music cues by mood, sound and exact runtime. Instant preview links.
Scored across 8 tools
Most tools target distinct actions: search_tracks (brief-based discovery), find_similar ('more like this'), fit_to_duration (runtime matching), cue_sheet (clearance/rights), and about/feedback are clearly separated. The main overlap is stye_get_track vs stye_list_versions, since get_track already returns 'every version that exists' while list_versions exists to enumerate delivery formats — an agent could reasonably pick either when asked about stems or cutdowns.
All tools share the stye_ prefix and most follow a verb_noun pattern (search_tracks, get_track, list_versions, find_similar, fit_to_duration). Minor deviation: about, cue_sheet, and feedback are bare nouns without a verb, but the overall scheme is predictable and readable.
Eight tools is well-scoped for a read-only production-music catalogue: discovery (search, similar, duration), detail (track, versions, cue sheet), plus meta (about, feedback). Each tool earns its place and none look redundant at the count level.
Core lifecycle is covered: find music by brief, refine by similarity or runtime, inspect a cue's full detail/versions, pull clearance data, and send feedback. Minor gaps: no dedicated album/collection browsing tool (albums are only reachable via a search filter) and no way to enumerate contexts except by passing an unknown name, though agents can work around both.
What this service is, how licensing works and what the server sees: the service's own licensing and privacy statements, with links to the full legal terms and the privacy policy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the response is licensing/privacy statements with links, which is useful content context, but no contradiction exists and little else is disclosed.
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?
It is a single front-loaded sentence with no wasted clauses. The phrasing repeats "service" twice, a minor redundancy, but overall it is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and annotations covering the safety profile, the description's job is to convey what is returned, which it does (statements plus links). Complete enough for a zero-arg informational tool, though it could state explicitly that it takes no arguments.
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 takes zero parameters, so there is nothing for the description to document; baseline 4 applies. No parameter-level clarification is needed.
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 the resource (service/about info, licensing, privacy) and what the caller gets (statements plus links to legal terms and privacy policy). It is distinguishable from the track-oriented siblings like stye_get_track or stye_search_tracks, though the phrasing is slightly circular ("What this service is ... the service's own licensing and privacy statements").
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?
There is no explicit statement of when to call this tool or how it relates to alternatives; usage is only weakly implied by the content being informational context about the service. No prerequisites or exclusions are given.
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. A field missing from the response is not on file in the catalogue; info@songstoyoureyes.com handles gaps. Licensing is arranged with the Songs To Your Eyes team, outside these tools.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The catalogue ID of a track: the `ref` field of a search or track result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds genuinely non-obvious semantics: a field absent from the response means it is not on file in the catalogue, and gaps are escalated to info@songstoyoureyes.com. That interprets the result rather than restating 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?
Two tight sentences with no filler; the payload contents come first and the gap-handling note follows. Slightly dense enumeration, but each clause carries 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?
With no output schema, the description carries the full burden of describing the return value, and it does so field by field (writers, society, IPI, publishers, shares, ISRC, album). It also preempts the most likely agent confusion, a missing field, by explaining what absence means and where to escalate.
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?
There is a single parameter with 100% schema description coverage, and the schema already explains that ref is the catalogue ID from a search or track result. The description adds no syntax or format 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?
The description names the specific resource and its full field set: every credited writer with role, society and IPI, every publisher with its share, plus ISRC and album. That is far more concrete than a sibling like stye_get_track would be. It does not explicitly contrast itself with siblings, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implicitly frames the use case ('the clearance data a broadcaster or PRO filing needs') and states an out-of-scope condition ('Licensing is arranged with the Songs To Your Eyes team, outside these tools'). However, it never says when to reach for this instead of stye_get_track or stye_list_versions, so the routing guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a short message to the catalogue team about how well results fit: a wrong-feeling page, a brief that found nothing, or praise worth keeping. It sends only with consented=true, which records that the user explicitly agreed to send this message; without it, nothing is sent. The message is stored with the brief and track it concerns and no user identifier (https://mcp.songstoyoureyes.com/privacy).
| 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, in their own words. | |
| consented | Yes | Whether the user explicitly agreed to send this feedback. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only declaring the generic mutation profile (readOnly=false, idempotent=false), the description supplies the material behavior: the hard consent gate ('only with consented=true... without it, nothing is sent') and the storage/anonymization policy ('stored with the brief and track it concerns and no user identifier'). That is exactly the kind of side-effect and privacy context annotations cannot 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?
Three tight sentences, front-loading what the tool does, then the consent precondition, then the data-handling note. Every sentence earns its place; the parenthetical privacy URL is the only mildly distracting element.
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 fire-and-forget reporting tool with no output schema, the description covers purpose, gating condition, and data handling, which is all an agent needs to call it correctly. It does not mention any success acknowledgement, but that is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both the message and consented fields are already documented in the schema. The description reinforces the meaning of consented and its gating effect, but adds no syntax or format detail beyond that, so the 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?
States a specific verb and resource ('sends a short message to the catalogue team') plus the subject matter ('how well results fit'), and enumerates the three concrete cases it covers. No sibling tool does feedback reporting, so the agent can route here unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear trigger conditions — a wrong-feeling page, a brief that found nothing, praise worth keeping — so the agent knows what belongs here. It does not state exclusions or point to alternative tools, but no sibling overlaps this capability.
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 editorial description of each cue together with its genres, moods and instrumentation, for 'more like this one' moments. It compares how cues are described, not their waveforms, so it is strong on character and mood and does not detect two cues as alike purely because they sound alike. Results are main mixes from other cue families, at most three per album, each with its listen_url.
| 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 read-only, idempotent, non-destructive, closed-world. The description adds real behavioral detail beyond that: results are main mixes from other cue families, capped at three per album, each carrying a listen_url. It does not cover pagination or ordering, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core operation, then the matching mechanism, then the result constraints. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully discloses the shape of the return (main mixes, other cue families, max three per album, listen_url). For a simple two-parameter read tool, an agent has everything needed 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 both parameters (ref, limit) are fully documented in the schema. The description only implies the ref and never mentions the limit knob beyond the album cap, so it adds nothing beyond the schema. 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 operation (find cues close in character to a given one) and the matching basis (editorial description, genres, moods, instrumentation). An agent can distinguish it from stye_search_tracks and stye_get_track without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Frames the use case ('more like this one' moments) and adds an explicit exclusion: it does not detect sonic/waveform similarity. No alternative sibling is named for the sonic case, so it falls short of a full when/when-not/alternatives treatment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds cues that fit an exact runtime, for a cut of known length such as a 30-second advert or a 90-second title sequence: music to license for a project, or anything about the Songs To Your Eyes catalogue.
Two kinds of result come back. Some cues already run close to the target length (fit='native'). Others are purpose-made short edits of a longer piece, cut down by the composer (fit='cutdown'), 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 public page where the cue plays, with cover art and a waveform. It is the only way a person can hear a cue: a cue listed without its listen_url cannot be auditioned.
The brief is matched on Songs To Your Eyes' own servers; it is not sent to any third-party AI service.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Optional sound brief, e.g. 'epic cinematic trailer'. | |
| limit | No | Maximum results (default 8, up to 25). | |
| 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). | |
| 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 readOnly/idempotent/non-destructive/closed-world, but the description adds genuinely non-obvious behavior: two result classes (fit='native' vs 'cutdown'), the sign convention of delta_s, the licence_ref vs ref distinction, and that a cue without a listen_url cannot be auditioned. It also discloses that the brief is matched on Songs To Your Eyes' own servers and never sent to a third-party AI service, a privacy trait annotations cannot 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?
Purpose is front-loaded in sentence one and the paragraphs are logically ordered (what it does → result kinds → field meanings → operational/privacy note). The catalogue clause in sentence one is dead weight and the listen_url paragraph is slightly over-explained, but overall it is tight and every other sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of return-value explanation and does so for the key fields (fit, delta_s, licence_ref, ref, listen_url), which is a lot for an 8-parameter tool. It omits pagination behavior for limit and does not enumerate the remaining result fields, so it is strong but not exhaustive.
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 every parameter (brief, limit, moods, composer, has_vocals, target_seconds, include_previews, tolerance_seconds) is already documented, and the baseline is 3. The description's added richness (fit, delta_s, licence_ref/ref) concerns returned fields rather than the inputs, so it does not meaningfully extend parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It states a specific verb+resource (finds cues matching an exact runtime) with concrete examples (30-second advert, 90-second title sequence), which cleanly separates it from stye_search_tracks and stye_find_similar. However, the trailing clause 'or anything about the Songs To Your Eyes catalogue' blurs its scope and overlaps the stye_about sibling, slightly diluting an otherwise precise statement.
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 triggering context — use it when you have a cut of known length — which is exactly the condition that selects this tool. It never names an alternative or an exclusion (e.g. when to prefer stye_search_tracks), so it stops short of full routing guidance.
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 its listen_url. For a track already found, or for what else a cue can be delivered as.
Every result carries listen_url, a permanent public page where the cue plays, with cover art and a waveform. It is the only way a person can hear a cue: a cue listed without its listen_url cannot be auditioned.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The catalogue ID of a track: the `ref` field of a search or track result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds meaningful context beyond that: results always carry a permanent public listen_url with cover art and waveform, and it flags the constraint that a cue without its listen_url cannot be auditioned. It does not cover failure modes for an invalid ref, but the added context is substantive.
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 field inventory is front-loaded and the second paragraph focuses on the single most important output, listen_url. It is slightly verbose about the listen_url page, but every sentence is on-topic and none is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by enumerating the returned fields and highlighting listen_url. Annotations cover the safety profile. The main omission is disambiguating against stye_list_versions, which leaves ambiguity about which tool to pick for version exploration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single param has 100% schema description coverage, so the schema already defines 'ref' as the catalogue ID. The description only indirectly reinforces this via 'For a track already found' and does not add format, range, or lookup details. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Get full details for one track') and enumerates what is returned: audio character, tempo, key, length, instrumentation, versions, and listen_url. It also distinguishes itself from search by scoping to 'a track already found'. However, it never clarifies its boundary against the sibling stye_list_versions, which the description's 'every version that exists of it' seems to overlap with, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'For a track already found, or for what else a cue can be delivered as' implies when to reach for it, but there is no explicit when-not guidance and no naming of alternatives. The overlap with stye_list_versions and stye_search_tracks is left for the agent to infer, which is a real gap given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every form a cue can be delivered in: the full-length mix plus, where they exist, timed cutdowns (15, 30, 60 seconds) built for standard ad and promo lengths, alternate mixes such as no-drums, underscore or instrumental for music that sits beneath dialogue, and individual instrument stems for rebalancing a track. A little under half of the catalogue's cues have at least one of these. Each version carries its own listen_url. Relevant when a cue is nearly right but needs to be shorter, quieter under a voice, or stripped back.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Any track ref, main mix or one of its versions; the whole family is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds real value by disclosing catalogue coverage ('a little under half of the catalogue's cues have at least one of these') and that each version carries its own listen_url. It doesn't discuss errors or pagination, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded, enumerating version types before qualifying with the coverage statistic and use case. Slightly long-winded in the alternate-mix clause, but every sentence carries 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?
No output schema exists, so the description carries the return-shape burden; it names the version categories and notes each has a listen_url, which is enough for an agent to know what comes back. A hint about response ordering or fallback when no versions exist would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already explains that any ref — main mix or a version — returns the whole family, so the description adds nothing beyond the schema. 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 — listing every deliverable form of a cue (full mix, timed cutdowns, alternate mixes, stems). It is clearly distinguishable from siblings like stye_get_track (single track fetch) or stye_fit_to_duration (duration fitting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete usage context: 'Relevant when a cue is nearly right but needs to be shorter, quieter under a voice, or stripped back.' It does not name an alternative tool (e.g., stye_fit_to_duration) or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the Songs To Your Eyes production-music catalogue for cues that fit a brief for a video, film, advert, trailer or podcast: music to license for a project, or anything about the Songs To Your Eyes catalogue.
The brief is matched by MEANING against an editorial description of how each cue behaves as well as against its tags, so a described scene, mood, instrumentation or arc ("tense investigative underscore that never resolves", "warm and hopeful for a charity film") matches far better than a single keyword.
LISTENING. Each result carries listen_url, a permanent public page where that cue plays. It is the only way a person can hear a cue: a cue listed without its listen_url cannot be auditioned. This holds for every list, an album listing included.
PRIVACY. When a brief has not been searched before, its text is sent to Google's Gemini API to interpret it; no identifier is sent.
FILTERS. Every filter is a hard constraint. Filters combine with AND, and a cue missing the tag a filter tests is excluded, so several filters together can empty a page. The brief carries soft qualities without excluding anything.
PAGES. One call returns one page of up to 25 cues (default 15); there is no pagination, and identical arguments return identical cues. A different brief, or the same need phrased from a different angle, returns different cues.
VOCALS. has_vocals=true selects songs with sung lead vocals and lyrics. Wordless vocal textures (background vocals, oohs and aahs, choir pads) are classed as instrumental, has_vocals=false; a request for "background vocals" is almost always a request for no lyrics. Texture words in the brief ("background vocals", "choir", "vocal hooks", "group singing") are detected server-side and applied as a hard requirement, so every result carries that texture and a short page reflects the catalogue's actual supply of it.
COMPOSERS. The composer filter matches the credited composer by partial name, with or
without a brief (with none, it lists that composer's cues). Each result's composer field
is the catalogue's own writer credit.
ANGLES. A page reflects one phrasing of a brief. Phrasings from different angles reach different parts of the whole catalogue: the literal angle (traditional instruments and idiom), the feel angle (texture, pulse and atmosphere with no instrument names, e.g. "hazy hypnotic modal groove, dusty and sun-baked") and the crossover angle (the setting's colour through another genre: desert funk, ethnic electronica, psychedelic world). The feel and crossover angles routinely surface the most distinctive picks, which a literal phrasing misses.
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 built on them loses its keyword match, while the sound of the place (oud, darbuka, qanun, hand percussion; desert, hypnotic, modal, dusty) matches.
ALBUMS. Albums are curated sets of about five cues built around one idea. A general search
returns at most two cues per album (max_per_album) so that a page spans the catalogue, and
albums_represented reports how many distinct albums the page drew on. The album filter
returns a whole set and lifts that cap. A recommendation built from a single album shows
one record's take on a brief rather than the catalogue's range.
EVENTS AND OCCASIONS. Tags naming a specific event (a festival, a holiday, an occasion) are on a handful of cues, not applied systematically: only 20 cues carry "Burning Man" while the catalogue holds ~1,900 electronic cues, and 39 carry "Festival". An event-tag match is therefore a narrow slice. The music an occasion implies reaches much further: house, techno, trance and rave for a festival; the emotional register, rather than the word, for a wedding.
CONTEXTS. The context parameter runs an owner-curated occasion search ('rave-club',
'christmas', 'halloween', 'summer' and others) against assignments precomputed from the
catalogue owner's translation rules: "rave" reaches the whole beat-driven electronic
palette, not just the cues that carry a festival tag. An unknown name returns the full
list of valid contexts. Country names (Lebanon, Morocco, Turkey...) are accepted and
generalise to their regional palette, where the catalogue's world coverage is deeper. Some
contexts are ambiguous (summer, a country or territory): they return results grouped into
2-4 labelled directions, each with its own slug, plus a question that tells them apart;
that slug passed as context returns the one direction.
AMBIGUOUS BRIEFS. Some briefs span genuinely different musical directions: "summer vibes" can mean tropical-house feelgood, chill-lounge, world/travel or sexy/fashion. A single search commits to one reading; the ambiguous contexts return the labelled spread.
REFERENCES. The catalogue's tags carry no artist, composer, film or brand names, so a reference searched verbatim ("a la Philip Glass", "like Stranger Things", "think Apple ads") finds little, while a description of its sound matches: Philip Glass is minimal pulsing arpeggios, piano and strings, hypnotic repetition; Trent Reznor meets M83 is dark industrial synths under huge emotive electronic swells; Stranger Things is a retro analog synth pulse, ominous but restrained.
NEGATIVES. Negation written into the brief does not subtract from a search. The exclude
parameter hard-drops any cue carrying the listed tags, spelling variants included. It
takes tag-shaped terms (instruments, moods, genres); soft qualities ("not too hard")
match better as positive wording in the brief ("restrained", "understated").
STEMS, CUTDOWNS AND KEYS. The catalogue holds ~43,000
stem versions and ~2,800 drums-only stems, and
~1,100 cues have a labelled :30 cutdown; each
result's versions counts what exists for that cue. The key filter matches briefs like
"preferably in E" (E matches both E and Em); ~7,100 mains
carry a key.
CLEAN LYRICS. explicit: true means the catalogue owner has flagged the cue's sung lyrics
as not clean.
LYRICS. 328 cues have lyrics on file, and the lyrics are in the full-text index, so words that are actually sung match. Matching is by wording, not subject: "a song about winning" finds lyrics containing "winning", not every song about victory. The catalogue is overwhelmingly instrumental, so a lyric match is a narrow slice on top of the musical match.
RESULTS. Each result describes one cue. listen_url is a permanent public page where the cue plays, with cover art and a waveform: it is how a person actually hears the music. Every playable row carries its own listen_url. The versions of a cue share one title and differ only by ref, so a link built by hand from a title or a ref can point at the wrong audio.
Also returned: title, album, album_title, composer (the catalogue's own writer credit), description (what it sounds like and what it suits), duration_s, bpm, key, has_vocals, explicit, genres, moods, instruments, use_cases, keywords (extra catalogue tags beyond those lists, such as tempo bands like 'Mid Tempo' and placements like 'TV Score'), and three editorial judgements: energy (low | low-building | moderate | building | high), resolves (whether it lands, or stays unresolved and tense) and vo_friendly (whether it leaves space for a voiceover). versions counts the stems, alternate mixes and shorter cuts that exist for the cue, and cutdown_lengths_s lists the cut lengths in seconds. ref is the catalogue's ID for the cue. preview_url, when requested, is a temporary streaming link that expires after 15 minutes; listen_url never expires.
A field absent from a row means the catalogue holds no data for it: an absent bpm means untagged, not slow; an absent composer means no usable credit; an absent cutdown_lengths_s means no timed cutdowns exist.
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); a clean file comes with a licence. preview_url 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). ~7,100 mains carry key data, about 44% of the catalogue; the filter excludes the rest. | |
| album | No | Only tracks from this album, by name ('Desert Funk') or catalogue code ('STYE1204'); partial names match. With no brief it lists the album; with one it searches inside it. Setting it lifts the per-album cap, so the whole set comes back from one record. | |
| 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 have their own filters; vocal texture (wordless backing vocals, choir pads) is matched from the brief. | |
| limit | No | Maximum results, up to 25 (default 15). One page per call: there is no pagination, and identical arguments return identical cues. | |
| 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. Around 54% of the catalogue has no tempo tag, and any BPM filter excludes all of those cues, good matches included; pace described in the brief has no such cost. | |
| context | No | Owner-curated occasion/context search (CONTEXTS in the description): a context name ('rave-club', 'christmas', 'halloween', 'summer') or a country name, which generalises to its regional palette. An unknown name returns the full list of valid contexts. Ambiguous contexts return results grouped into labelled directions plus a question for the user. | |
| exclude | No | Tags to hard-drop: any cue carrying any of them is removed (a brief's exclusions, such as '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 are matched through the brief. | |
| composer | No | Only tracks credited to this composer/artist. Partial names match ('Albeg' finds 'Yair Albeg Wein'), case-insensitive, with or without a brief. Every result carries its `composer` credit. | |
| 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), which count as instrumental here. 'Background vocals' in a request almost always means no lyrics. Omitted = 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 | Maximum cues from any one album on the page, so results spread across the catalogue instead of returning a block from one record. Default 2 for a general search; ignored when filtering 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 readOnly/idempotent/non-destructive, yet the description layers on real behavioral context: briefs are sent to Gemini when novel (privacy), filters are hard AND constraints that can empty a page, no pagination and identical args return identical cues, vocal-texture words become a hard requirement, and preview links expire in 15 minutes while listen_url never does. None of this is in 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?
It is front-loaded well with a strong opening sentence and headed sections, but it is very long and contains real duplication: listen_url is explained in both LISTENING and RESULTS, and the versions/cutdown concept is restated. Some of the coverage is warranted by 19 parameters and no output schema, but several sentences do not earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 19-parameter, no-output-schema tool, the RESULTS section enumerates every returned field (composer, energy, resolves, vo_friendly, versions, ref, etc.) plus the meaning of absent fields and the watermarking behaviour of downloads. An agent has everything needed to interpret and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the per-parameter schema text is already unusually rich (key major/minor equivalence, BPM exclusion cost, has_vocals texture rules), so the description's per-param additions are largely duplicative. It does add genuine cross-parameter meaning the schema lacks: 'Every filter is a hard constraint... combine with AND, and a cue missing the tag a filter tests is excluded', plus the brief-vs-filter soft/hard split.
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 first line gives a specific verb and resource: 'Searches the Songs To Your Eyes production-music catalogue for cues that fit a brief for a video, film, advert, trailer or podcast'. The scope and subject matter are unambiguous. It does not explicitly distinguish itself from siblings like stye_find_similar (find by similarity to a track) and stye_get_track, so it stops short of full sibling differentiation.
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?
Extensive when/when-not guidance: it advises that BPM filters exclude the ~54% untagged cues while pace in the brief has no such cost, that negation in the brief does not subtract and `exclude` should be used instead, and that the album filter lifts the per-album cap. It also prescribes phrasing strategies (literal vs feel vs crossover angles) and how references should be re-described. This is far beyond implied usage.
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_cue_sheet1 field changedInput schema / properties / ref / descriptionPrevious value: -"A track ref from any other tool's results."New value: +"The catalogue ID of a track: the `ref` field of a search or track result."stye_feedback2 fields changedInput schema / properties / consented / descriptionPrevious value: -"True ONLY if the user explicitly agreed to send this feedback."New value: +"Whether the user explicitly agreed to send this feedback."Input schema / properties / message / descriptionPrevious value: -"The user's feedback, verbatim."New value: +"The user's feedback, in their own words."stye_fit_to_duration2 fields changedInput schema / properties / has_vocals / descriptionPrevious value: -"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."New value: +"true = songs with sung lead vocals/lyrics only. false = everything else, including wordless vocal textures (background vocals, choir)."Input schema / properties / limit / descriptionAdded value: +"Maximum results (default 8, up to 25)."stye_get_track1 field changedInput schema / properties / ref / descriptionPrevious value: -"A track ref from any other tool's results."New value: +"The catalogue ID of a track: the `ref` field of a search or track result."stye_list_versions1 field changedInput schema / properties / ref / descriptionPrevious value: -"Any track ref — main mix or one of its versions; the whole family is returned."New value: +"Any track ref, main mix or one of its versions; the whole family is returned."stye_search_tracks10 fields 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). 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."New value: +"Only tracks from this album, by name ('Desert Funk') or catalogue code ('STYE1204'); partial names match. With no brief it lists the album; with one it searches inside it. Setting it lifts the per-album cap, so the whole set comes back from one record."Input schema / properties / bpm_min / descriptionPrevious value: -"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."New value: +"Minimum BPM. Around 54% of the catalogue has no tempo tag, and any BPM filter excludes all of those cues, good matches included; pace described in the brief has no such cost."Input schema / properties / brief / descriptionPrevious value: -"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."New value: +"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 have their own filters; vocal texture (wordless backing vocals, choir pads) is matched from the brief."Input schema / properties / composer / descriptionPrevious value: -"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."New value: +"Only tracks credited to this composer/artist. Partial names match ('Albeg' finds 'Yair Albeg Wein'), case-insensitive, with or without a brief. Every result carries its `composer` credit."Input schema / properties / context / descriptionPrevious value: -"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."New value: +"Owner-curated occasion/context search (CONTEXTS in the description): a context name ('rave-club', 'christmas', 'halloween', 'summer') or a country name, which generalises to its regional palette. An unknown name returns the full list of valid contexts. Ambiguous contexts return results grouped into labelled directions plus a question for the user."Input schema / properties / exclude / descriptionPrevious value: -"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."New value: +"Tags to hard-drop: any cue carrying any of them is removed (a brief's exclusions, such as '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 are matched through the brief."Input schema / properties / has_vocals / descriptionPrevious value: -"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."New value: +"true = songs with sung lead vocals and lyrics. false = everything else, including cues with wordless vocal textures (background vocals, oohs/aahs, choir pads), which count as instrumental here. 'Background vocals' in a request almost always means no lyrics. Omitted = both."Input 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,100 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). ~7,100 mains carry key data, about 44% of the catalogue; the filter excludes the rest."Input schema / properties / limit / descriptionPrevious 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."New value: +"Maximum results, up to 25 (default 15). One page per call: there is no pagination, and identical arguments return identical cues."Input schema / properties / max_per_album / descriptionPrevious value: -"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."New value: +"Maximum cues from any one album on the page, so results spread across the catalogue instead of returning a block from one record. Default 2 for a general search; ignored when filtering by album or composer."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_similarSearch 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.
Royalty-free music fitted to your length: find, generate, adjust and download tracks and stems.
Find and license original songs to record. Hear every song in many production styles.
Add one secure layer between your agents and this server.