Skip to main content
Glama

AINSOF

by io.ainsof.mcp
OverviewDiscussionsAdmin

analyze_video

Destructive

Before AINSOF works with a video the person signs in once on ainsof.io (Google or email): without a sign_in_code this returns sign_in_required with a link to show them; after they sign in, call again with the same arguments plus that sign_in_code. Analyze a downloadable video, up to 15 minutes, for soundtrack planning without editing or scoring it. Fetches the linked file, creates or reuses an analysis job, stores analysis results and records operational activity. Returns film: what kind of video it is, the story it tells, how its feeling moves, its atmosphere and energy, whether it already has music, and the music that fits it (style, moods, instruments, tempo, and music.search, a description ready for find_soundtrack). Reading the film takes up to a minute; a still_running reply means call again with the same video_url. Also returns measured duration, frame rate, resolution, audio-stream presence, detected cut timestamps and edit-pace metrics. When extraction succeeds, includes up to 12 timestamped storyboard images; longer videos may have only their longest detected shots represented, so the images do not cover every moment. An optional speech transcript covers at most the first two minutes and may be truncated or unavailable; its absence does not establish silence. An expired temporary AINSOF-uploaded source copy may be deleted when processing finishes; the local original is unchanged. AINSOF keeps the storyboard images, transcript, optional user_request and a reduced-resolution review copy for 30 days, then deletes them.

Input Schema

NameRequiredDescriptionDefault
video_urlYeslink to the video
music_intentNooptional — the music the user wants, in at most 8 English words, no names (e.g. 'tense build, minimal, no vocals'). Kept as anonymous usage statistics.
project_typeNooptional — what kind of project the video is. Kept as anonymous usage statistics.
sign_in_codeNothe sign_in_code AINSOF returned with its sign-in link, once the person has signed in. Pass it to every video tool in this conversation.
user_requestNooptional — in one sentence, what the user wants the music to do for this video, in their own words (e.g. 'tense build to the reveal at the end'). Kept by AINSOF for 30 days to review how well the music fit, then deleted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / sign_in_code
      Added value: +{
+  "description": "the sign_in_code AINSOF returned with its sign-in link, once the person has signed in. Pass it to every video tool in this conversation.",
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • addedInput schema / properties / music_intent
      Added value: +{
+  "description": "optional — the music the user wants, in at most 8 English words, no names (e.g. 'tense build, minimal, no vocals'). Kept as anonymous usage statistics.",
+  "type": "string"
+}
    • addedInput schema / properties / project_type
      Added value: +{
+  "description": "optional — what kind of project the video is. Kept as anonymous usage statistics.",
+  "enum": [
+    "ad",
+    "social",
+    "documentary",
+    "film",
+    "trailer",
+    "game",
+    "corporate",
+    "event",
+    "podcast",
+    "music_video",
+    "other"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / user_request
      Added value: +{
+  "description": "optional — in one sentence, what the user wants the music to do for this video, in their own words (e.g. 'tense build to the reveal at the end'). Kept by AINSOF for 30 days to review how well the music fit, then deleted.",
+  "type": "string"
+}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations say destructiveHint=true and share almost nothing else, yet the description discloses the concrete side effect (an expired temporary AINSOF-uploaded source copy may be deleted; the local original is unchanged), the 30-day retention of storyboard images, transcript, user_request and review copy, and the fetch of an external file (openWorldHint). It also reconciles the non-readOnly flag by explicitly denying any edit or scoring of the video.

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

Conciseness4/5

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

Front-loaded with the mandatory auth step, which is the right priority, and most sentences carry distinct information about returns, timing and retention. It is dense to the point of being a wall of text, and 'creates or reuses an analysis job, stores analysis results and records operational activity' is implementation boilerplate that could be cut.

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?

With no output schema and destructive/openWorld annotations, the description carries the full burden and does: it enumerates the returned fields (film classification, music fit including music.search, duration, frame rate, resolution, audio presence, cut timestamps, pace metrics), the up-to-12 storyboard limits, and transcript truncation caveats. An agent can invoke and interpret this without opening anything else.

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 description coverage is 100%, so the baseline is 3, but the description adds workflow meaning beyond the schema: sign_in_code is a per-conversation credential to pass to every video tool and is the key to clearing sign_in_required, and user_request is the phrasing that gets retained for 30 days. It does not add syntax or constraints for music_intent/project_type.

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?

States a specific verb and resource ('Analyze a downloadable video'), bounds it ('up to 15 minutes'), and carves out scope explicitly ('for soundtrack planning without editing or scoring it'), which separates it from scoring/edit siblings. It also names the artifact it produces ('film').

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?

Gives clear operational guidance: sign in once, expect sign_in_required without a code, re-call with the same arguments plus sign_in_code, and re-call on still_running. It implies the alternative (scoring/editing tools) via the exclusion but never names a sibling tool such as score_my_video or cue_sheet.

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