AINSOF

search_by_reference

Find AINSOF music that SOUNDS LIKE a reference. Accepts a YouTube, Spotify, Apple Music or Deezer link, or 'artist - title'. SoundCloud is not supported because it exposes no permitted preview clip; TikTok is not supported because its published metadata identifies the post caption, not the recording. Ask for the artist and title instead. Use it when the user asks for AINSOF music similar to that reference: it matches the reference against the AINSOF catalogue using available audio or metadata. Supply musical_description with concrete style, groove and instruments when supported by the user's description or reliable knowledge of the reference; omit it if uncertain. This adds a separate catalogue-context search. Returned candidates are not verified sound-alikes; musical suitability requires listening. Records by other artists cannot be licensed from AINSOF, so this returns our cues rather than a reading list. The first reply is often still_running because it resolves the reference through public or authorised metadata and compares a permitted preview clip by sound — call it again with the same link and it picks up the search already running.

Input Schema

TableJSON Schema

Name	Required	Description
`link`	Yes
`top_k`	No
`musical_styles`	No	Known English genre labels from the user's request or reliable knowledge of the reference, e.g. disco, funk. Omit if uncertain. Matches catalogue genre tags (including single words) and may return fewer cues. Multiple styles are alternatives, not proof of their combination. Never invent a genre to fill this field.
`musical_description`	No	Known musical style, groove and instrumentation, preferably in English. Include the user's constraints. Do not invent traits or treat the artist/title as a musical description.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 8, 2026

addedInput schema / properties / musical_styles

Added value: +{
+  "description": "Known English genre labels from the user's request or reliable knowledge of the reference, e.g. disco, funk. Omit if uncertain. Matches catalogue genre tags (including single words) and may return fewer cues. Multiple styles are alternatives, not proof of their combination. Never invent a genre to fill this field.",
+  "items": {
+    "maxLength": 80,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 4,
+  "type": "array"
+}

Changed1 schema field changedSep 8, 2026

addedInput schema / properties / musical_description

Added value: +{
+  "description": "Known musical style, groove and instrumentation, preferably in English. Include the user's constraints. Do not invent traits or treat the artist/title as a musical description.",
+  "maxLength": 1000,
+  "type": "string"
+}

First observedAug 7, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reveals important behaviors beyond annotations: the first reply is often still_running, calling again resumes the running search, candidates are not verified sound-alikes, and unsupported platforms are explained by their metadata/preview limitations. This is exactly the kind of non-obvious runtime behavior an agent needs to know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is long, every sentence carries operational value: input formats, unsupported sources, invocation timing, caveats about verification, and the still_running retry behavior. It is front-loaded with the core purpose and remains dense rather than padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, reference-matching tool with no output schema and minimal annotations, the description covers input constraints, unsupported platforms, output caveats, and asynchronous behavior. The only minor omission is exact return shape, but the guidance that results are 'cues' requiring listening is sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, but the description compensates substantially for the critical parameters: it defines accepted link formats for 'link' and explains when and how to supply musical_description. It does not explicitly describe top_k, though that parameter is fairly self-explanatory and has a schema default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Find AINSOF music that SOUNDS LIKE a reference.' It then defines the exact input types and the matching approach, which clearly separates it from sibling tools like search_music or get_track. The scope ('AINSOF catalogue', 'our cues rather than a reading list') further pins down what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool: 'Use it when the user asks for AINSOF music similar to that reference.' It also gives when-not guidance for SoundCloud and TikTok and instructs the agent to ask for artist/title instead. It does not name sibling tools as alternatives, but the usage context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All AINSOF tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?