AINSOF

find_soundtrack

Use this when the user wants music for a specific video and its length is known. If the length is unknown, use search_music instead. Find music for a video. Given the video's length and a description of it, returns eight cues from the AINSOF catalog when suitable cues are available, preferring playable versions that fit the requested duration. When an exact-length cut is unavailable, for_your_video explains the required edit. Every result comes with its composer, publisher and a preview to listen to. Use this when someone asks for music or a soundtrack for a video and its exact duration is available. Each call is self-contained: for a refinement, describe the current musical requirements including the latest change. Send only the video description and musical requirements, never chat transcripts, assistant replies or unrelated personal information. Pass the customer's musical request in their original language, preserving their words, exclusions and durations. Do not add instruments, genres, mood, energy or vocal restrictions that they did not ask for. For a refinement, combine only the customer's established requirements and latest change, not suggestions from an assistant. One search returns evaluated matches or alternatives; present that result before proposing another direction. An unavailable search is a technical failure, not an empty catalog: explain it and do not automatically repeat or broaden the request. A user-requested retry remains possible.

Input Schema

Name	Required	Description
`scope`	No	Optional library restriction; omit to let the request select the library.
`product`	No
`description`	Yes	Describe the video, mood or music wanted, in the user's language. Required; duration alone is insufficient.
`cuts_per_min`	No	edit pace, if known
`duration_sec`	Yes	the video's length in seconds
`has_narration`	No	true if anyone speaks over it

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 14, 2026

removedInput schema / properties / clarification

Removed value: -{
-  "maxLength": 500,
-  "type": "string"
-}

removedInput schema / properties / continue_previous
```
Removed value: -{
-  "type": "boolean"
-}
```

removedInput schema / properties / history

Removed value: -{
-  "description": "Only the current search conversation, in order. Include the original user brief; mark its first user turn contextStart=true. Exclude older topics.",
-  "items": {
-    "properties": {
-      "answerTo": {
-        "maxLength": 500,
-        "type": "string"
-      },
-      "contextStart": {
-        "description": "True on the first user turn of the active search topic.",
-        "type": "boolean"
-      },
-      "role": {
-        "enum": [
-          "user",
-          "assistant"
-        ],
-        "type": "string"
-      },
-      "text": {
-        "maxLength": 600,
-        "type": "string"
-      }
-    },
-    "required": [
-      "role",
-      "text"
-    ],
-    "type": "object"
-  },
-  "maxItems": 8,
-  "type": "array"
-}

Changed7 schema fields changedOct 14, 2026

addedInput schema / properties / clarification

Added value: +{
+  "maxLength": 500,
+  "type": "string"
+}

addedInput schema / properties / continue_previous
```
Added value: +{
+  "type": "boolean"
+}
```

changedInput schema / properties / description / description

Previous value: -"what the video shows, in musical terms"New value: +"Describe the video, mood or music wanted, in the user's language. Required; duration alone is insufficient."

addedInput schema / properties / description / minLength
```
Added value: +1
```

addedInput schema / properties / history

Added value: +{
+  "description": "Only the current search conversation, in order. Include the original user brief; mark its first user turn contextStart=true. Exclude older topics.",
+  "items": {
+    "properties": {
+      "answerTo": {
+        "maxLength": 500,
+        "type": "string"
+      },
+      "contextStart": {
+        "description": "True on the first user turn of the active search topic.",
+        "type": "boolean"
+      },
+      "role": {
+        "enum": [
+          "user",
+          "assistant"
+        ],
+        "type": "string"
+      },
+      "text": {
+        "maxLength": 600,
+        "type": "string"
+      }
+    },
+    "required": [
+      "role",
+      "text"
+    ],
+    "type": "object"
+  },
+  "maxItems": 8,
+  "type": "array"
+}

addedInput schema / properties / scope

Added value: +{
+  "description": "Optional library restriction; omit to let the request select the library.",
+  "enum": [
+    "music",
+    "sfx"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "duration_sec"
-]New value: +[
+  "duration_sec",
+  "description"
+]

First observedAug 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond the annotations it discloses result count (eight cues), selection preference (playable versions fitting duration), what happens on a near miss ('for_your_video explains the required edit'), payload contents (composer, publisher, preview), and that calls are self-contained so refinements must restate requirements. It also defines failure semantics ('an unavailable search is a technical failure, not an empty catalog'), though it omits rate limits or auth expectations.

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

Conciseness3/5

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

Front-loaded with the routing condition, which is good, but the description repeats itself: the when-to-use condition appears twice ('when the user wants music for a specific video and its length is known' and 'when someone asks for music or a soundtrack for a video and its exact duration is available'), and 'Find music for a video' duplicates the title. Several sentences could be merged without losing content.

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

Completeness4/5

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

With no output schema, the description takes on the return-value burden and does it well (cue count, metadata per result, preview, edit explanation on length mismatch), and it covers refinements and failure cases. Minor gaps remain around the optional scope/product/cuts_per_min parameters and what an 'evaluated match' versus an 'alternative' looks like.

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 83%, so the schema already carries the baseline, but the description adds real meaning the schema does not: pass the user's request in their original language, preserve exclusions and durations, and do not invent instruments, genres, moods, energy, or vocal restrictions. It also excludes chat transcripts and assistant replies from the description field, which is guidance the schema's 'Describe the video...' text does not convey.

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 states a specific verb and resource ('Find music for a video', returns cues from the AINSOF catalog) and explicitly distinguishes itself from the sibling search_music by the known-vs-unknown duration condition. An agent can route between find_soundtrack and search_music without opening either schema.

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

Usage Guidelines5/5

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

It names the alternative (search_music) and the exact condition that selects it (length unknown), then adds a full refinement protocol ('for a refinement, describe the current musical requirements including the latest change'), rules for what NOT to include, and an explicit retry policy for unavailable searches. When-to-use, when-not-to-use, and alternatives are all present.

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?