Skip to main content
Glama

AINSOF

by io.ainsof.mcp
OverviewDiscussionsAdmin

fit_to_length

Use this when the user has chosen an AINSOF cue and needs it at a specific length — a 15-second ad, a 6-second bumper, a loop. It edits the composer's own recording; it does not generate new music. Cut one catalog cue to the length you need — for an ad, a reel, a sting or a video — the way an editor would: the song's opening, a jump of whole bars, and the song's REAL ending ringing out. Never stretched, never faded in the middle. kind='length' returns the nearest MUSICAL length (ask for 5 and you may get 6-8 seconds, so the ending still lands); kind='video' returns exactly seconds with the final hit before the last frame; kind='loop' returns a seamless loop of whole bars close to seconds. hit_at puts the song's arrival (its climax) on that second — use it for a reveal or a logo. stems=true also cuts every stem at the same points. Returns a listen link and a zip (MP3 192k mix + stems), kept 7 days. Identify the cue by the track_id or title search_music returned. For an ordinary request such as 'an 11-second version', use kind='length' and report the returned musical duration. Use kind='video' only when the user supplies a video's duration or explicitly asks for an exact duration. Do not carry a previous test's exact-length setting into a new request. When the user asks you to create, shorten or adapt a selected cue to a duration, call fit_to_length with that cue and the requested seconds. This works for arbitrary durations from 1 to 300 seconds, not just stock 15/30/40/60-second cuts or clips below 15 seconds. Preserve their chosen source version (for example NO_VOCALS); never silently use MAIN instead. If no cue has been chosen, search using their musical brief and help them choose first; a search result is not a newly generated edit. When status is processing, continue the same returned retry arguments without asking the user to repeat their request. Do not claim the edit is ready until status is ready and the returned edit links exist. Reply in the user's language, naming the cue, requested duration and actual duration. Show the supplied player and a clearly labeled download link; never show the source track's audio as the generated edit.

Input Schema

NameRequiredDescriptionDefault
kindNoFor an ordinary request such as 'an 11-second version', use kind='length' and report the returned musical duration. Use kind='video' only when the user supplies a video's duration or explicitly asks for an exact duration. Do not carry a previous test's exact-length setting into a new request. Use loop for an explicitly requested loop.
stemsNoalso cut every stem the same way
hit_atNooptional: the second where the song's arrival should land
secondsYesthe length you need (for kind='video', the video's length)
versionNooptional: cut from this version instead of MAIN
track_idYese.g. 'AIN-CAT 038_007', or the cue's title

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / kind / description
      Previous value: -"length (default) · video (exact length) · loop"New value: +"For an ordinary request such as 'an 11-second version', use kind='length' and report the returned musical duration. Use kind='video' only when the user supplies a video's duration or explicitly asks for an exact duration. Do not carry a previous test's exact-length setting into a new request. Use loop for an explicitly requested loop."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=false but say nothing operational. The description fills that gap: results expire after 7 days, returns a listen link plus MP3 192k mix and stems zip, processing status must reach 'ready' before claiming success, and retry arguments should be reused. This is substantially more than the 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.

Conciseness3/5

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

The core purpose is front-loaded in the first sentence, but the body is a long policy wall with loops of instruction, some of which duplicates the enum descriptions already in the schema. Much of it earns its place as workflow guidance, yet it is denser and longer than needed for selection and invocation.

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?

There is no output schema, so the description carries the return contract itself and does so fully: listen link, downloadable zip, audio format, retention window, and async status handling. An agent has everything required to call it and report back correctly.

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 already 100%, so the baseline is 3, but the description adds outcome-level meaning the schema lacks: the musical-quantization behavior ('ask for 5 and you may get 6-8 seconds'), the final-hit-before-last-frame behavior for kind='video', hit_at placing the climax on a given second, and the directive to preserve the chosen version (e.g. NO_VOCALS) rather than defaulting to MAIN.

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 names a specific verb and resource ('Cut one catalog cue to the length you need') and immediately scopes it against the nearest misconception: 'It edits the composer's own recording; it does not generate new music.' It is easily distinguished from siblings like search_music or deliver_score.

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 gives explicit routing rules: kind='length' for ordinary requests, kind='video' only when a video duration is supplied or exactness is demanded, kind='loop' for loops, and it names the fallback (search first if no cue is chosen). It also states an anti-pattern ('Do not carry a previous test's exact-length setting into a new request') and what to do during async processing.

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

All AINSOF toolsInspect
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