Skip to main content
Glama
sonilo-ai

Sonilo MCP

Official
by sonilo-ai
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Sonilo MCP Server

An MCP (Model Context Protocol) server that exposes Sonilo's licensed music and sound-effects API to MCP-compatible clients (Claude Code, Claude Desktop, Codex).

The flagship tool is video_to_music: hand it your finished video and it composes an original soundtrack matched to the cut — the music follows the pacing, emotion, and edits because the model saw them. Length matches the video automatically. Every track is licensed and safe for commercial use (terms apply). text_to_music is also available for fixed-length tracks with no video to match.

For sound design, video_to_sfx watches your video and generates matching sound effects, returned as a standalone audio file. text_to_sfx generates a standalone effect from a description.

▶ Example result — an AI-generated trailer with its soundtrack composed by video_to_music from the assembled cut. For recipes covering any AI-video pipeline (stitch → grade → add music → mux), see the Sonilo video-to-music cookbook.

Quickstart with Claude Code

Sign in once with the CLI, then add the server with no secret in the config:

npm install -g sonilo-cli && sonilo login
claude mcp add sonilo -- uvx sonilo-mcp

Or hold an API key yourself — get one from the Sonilo dashboard:

claude mcp add sonilo --env SONILO_API_KEY=sk-... -- uvx sonilo-mcp

Then start a session and ask, e.g. "Make background music that matches this video: ~/Desktop/promo.mp4."

Related MCP server: Spotify MCP Server

Why Sonilo

  • Video-to-music — give it a video and Sonilo composes a full-length score matched to its pacing, motion, and emotion. Transitions and beat drops align to your cut points, and the track matches the video's duration exactly — no prompts or manual syncing required.

  • Text-to-music — generate tracks from a text description (genre, mood, tempo, instrumentation) at an exact duration (1–360s).

  • Video-to-SFX — Sonilo watches the video and generates sound effects for what it sees. You get the SFX as a standalone audio file. Optional segments let you script effects to specific time ranges ([{start, end, prompt}]).

  • Text-to-SFX — generate a standalone sound effect from a description (1–180s), in wav, mp3, aac, or flac.

  • Fully licensed, commercial-safe — music licensed via Shutterstock; every generated track is cleared for commercial use on social, brand content, and advertising, with no Content ID worries.

  • Video-to-sound — generate music and sound effects for the same clip in one call, mixed into a single balanced soundtrack. Get back the mixed audio, or a new video with it muxed in.

  • Multiple variants per call — text_to_music, video_to_music, video_to_video_music, video_to_sound, and video_to_video_sound accept variants_num (1–10, default 1): generate several distinct creative directions in one request instead of re-rolling one at a time. Cost scales linearly with N, and N > 1 is never covered by the free trial.

  • Instrument stems — text_to_music and video_to_music accept stems=true: get the generated track additionally split into drums, bass, vocals and other, at no extra charge. Separation adds a few minutes; on video_to_music it splits the generated music, never the video's own audio.

  • Pay as you go — billed only for the seconds of music you generate. Self-serve accounts start with free runs on every endpoint except dubbing, no card required: 2 each on text-to-music, text-to-sfx and audio-ducking, and 1 each on video-to-music, video-to-sfx, video-to-video-music, video-to-video-sfx, video-to-sound and video-to-video-sound. After that, calls bill at the normal rate. dubbing has zero free runs and is billed from the first call — it charges video duration × number of languages, so a free run on it would be worth far more than on any other endpoint.

Audio Playback Dependencies

The play_audio tool requires PortAudio at runtime (for sounddevice). On macOS/Linux, install via:

  • macOS: brew install portaudio

  • Debian/Ubuntu: sudo apt-get install libportaudio2

uvx sonilo-mcp and pip install will pull the Python bindings, but the system PortAudio library must be installed separately. The other tools (text_to_music, video_to_music, text_to_sfx, video_to_sfx, audio_ducking, get_sfx_task, get_account_services, get_usage) work without PortAudio.

Quickstart with Claude Desktop

  1. Authenticate, either way round:

    • Sign in with the CLI — npm install -g sonilo-cli && sonilo login — and leave "env": {} below. Nothing secret goes in the config file.

    • Or get an API key from the Sonilo dashboard and put it in "env".

  2. Install the uv package manager (provides uvx):

    curl -LsSf https://astral.sh/uv/install.sh | sh

    See the uv repo for other install methods.

  3. Go to Claude > Settings > Developer > Edit Config > claude_desktop_config.json to include the following:

    {
  "mcpServers": {
    "sonilo": {
      "command": "uvx",
      "args": ["sonilo-mcp"],
      "env": {}
    }
  }
}

    That is the whole config when you have signed in with sonilo login. To hold a key instead, or to change the defaults:

    "env": {
  "SONILO_API_KEY": "sk-...",
  "SONILO_API_URL": "https://api.sonilo.com",
  "TIME_OUT_SECONDS": "600"
}

  4. Restart Claude Desktop. You should see the Sonilo tools available in the tool menu.

Quickstart with Codex

Signed in with the CLI (npm install -g sonilo-cli && sonilo login), the whole setup is one command:

codex mcp add sonilo -- uvx sonilo-mcp

Or, holding a key yourself:

codex mcp add sonilo --env SONILO_API_KEY=sk-... -- uvx sonilo-mcp

To configure it by hand instead:

  1. Get your API key from the Sonilo dashboard — or skip this step if you signed in with sonilo login.

  2. Install the uv package manager (provides uvx):

    curl -LsSf https://astral.sh/uv/install.sh | sh

  3. **Go to Codex > Settings > MCP servers to fill out the following:

alt text

Or you can add the server** to ~/.codex/config.toml:

[mcp_servers.sonilo]
command = "uvx"
args = ["sonilo-mcp"]

# Omit this whole block when you have signed in with `sonilo login`.
[mcp_servers.sonilo.env]
SONILO_API_KEY = "sk-..."
SONILO_API_URL = "https://api.sonilo.com"
TIME_OUT_SECONDS = "600"

  1. Restart Codex (or start a new session), then run /mcp to confirm sonilo is connected and its tools are listed.

Example usage

Once the server is connected, just ask your assistant in natural language. For example:

  • "Make background music that matches this video: ~/Desktop/promo.mp4."

  • "Compose music for https://example.com/clip.mp4 with a calm, ambient style."

  • "I stitched my AI-generated clips into ~/Desktop/trailer.mp4 — add a soundtrack that matches the cut."

  • "Use Sonilo mcp to generate 30 seconds of upbeat lo-fi hip-hop for a study playlist and save it to my Desktop."

  • "Use Sonilo to write an epic orchestral cinematic track, about 60 seconds long."

  • "What Sonilo services and limits does my account have?"

  • "Show my Sonilo usage for the last 7 days."

  • "Play the track you just generated."

The assistant will call the matching tool (text_to_music, video_to_music, text_to_sfx, video_to_sfx, audio_ducking, get_sfx_task, get_account_services, get_usage, or play_audio) and save generated audio to your configured output directory.

Configuration

Authentication

The server takes its key from SONILO_API_KEY if that is set, and otherwise from the credential written by sonilo login (~/.config/sonilo/credentials.json, or $XDG_CONFIG_HOME/sonilo/). The environment variable wins on purpose, so any config that already sets it keeps resolving to the same account after an upgrade.

The credential is looked up by the server's own SONILO_API_URL, so a staging server never picks up a production sign-in. This server only ever reads the file: run sonilo login again to renew it (keys from a sign-in expire after 90 days) and sonilo logout to revoke it.

Environment Variables

Variable

Default

Description

SONILO_API_KEY

(from sonilo login)

Bearer token. Required only if you have not signed in with the CLI.

SONILO_API_URL

https://api.sonilo.com

Public API base URL.

SONILO_MCP_BASE_PATH

~/Desktop

Default output directory and base for relative input paths. Also the confinement boundary (see below).

SONILO_MCP_ALLOW_ANY_PATH

false

Set to true to let tools read/write files outside SONILO_MCP_BASE_PATH.

TIME_OUT_SECONDS

600

Generation timeout, in seconds. Aligned with the backend's read timeout.

File access & confinement

By default, the file tools (video_to_music input, play_audio, and any output_directory) are confined to SONILO_MCP_BASE_PATH. Paths that resolve outside it (after symlink resolution) are rejected. This limits the blast radius if a client is tricked into reading or exfiltrating arbitrary files. To opt out — e.g. to read a video from elsewhere on disk — set SONILO_MCP_ALLOW_ANY_PATH=true.

Tools

Tool

Description

Cost

text_to_music(prompt, duration, output_format?, variants_num?, stems?, output_directory?)

Generate music from a text prompt. variants_num (1–10, default 1) generates that many distinct variants in one request, each with its own title; N > 1 forces the backend's async mode automatically and is never covered by the free trial. stems (default false) also saves the track split into four separate instrument tracks — drums, bass, vocals and other — at no extra charge; it adds a few minutes (the call waits up to 40 min) and forces the backend's async mode automatically. A stems_error note in the result means only the free separation failed or was skipped — the music itself is fine.

✅

video_to_music(video_path? | video_url?, prompt?, preserve_speech?, variants_num?, prompt_influence?, stems?, output_directory?)

Generate music matched to a video. Max duration 360s (6 min); subject to the account's upload-size cap (typically 300 MB). preserve_speech (default false) keeps the source speech in the result — you also get a vocals speech stem and a ready-to-use mux; when set, the call runs the backend's async generation mode internally instead of streaming. variants_num (1–10, default 1) works the same as text_to_music's. prompt_influence (0–1, API default 0.5) sets how strongly the generated music follows the prompt; omit it unless you want stricter or looser prompt adherence. Free, and works in both the streaming and async modes. stems (default false) works the same as text_to_music's — it splits the generated music, never the video's own audio.

✅

text_to_sfx(prompt, duration, audio_format?, output_directory?)

Generate a sound effect from text. Duration 1–180s; formats wav/mp3/aac/flac (default aac).

✅

video_to_sfx(video_path? | video_url?, prompt?, segments?, audio_format?, output_directory?)

Generate SFX for a video; saves the generated SFX audio. Max video duration 480s (8 min).

✅

video_to_video_music(video_path? | video_url?, prompt?, segments?, keep_original_sound?, ducking?, preserve_speech?, variants_num?, prompt_influence?, output_directory?)

Generate music for a video and return a new .mp4 with it muxed in. By default the result's audio is the generated music alone — the source's own audio is removed. Pass keep_original_sound=true to keep the whole source track with the music statically mixed under it, adding ducking=true to dip the music under the voice instead; or preserve_speech=true to keep only the isolated speech. keep_original_sound supersedes preserve_speech. Input must carry H.264/HEVC/VP9/AV1 (mp4, mov, m4v, webm); animated gif and VP8 webm are rejected. Max video duration 360s (6 min). variants_num (1–10, default 1) saves one .mp4 per variant. prompt_influence (0–1, API default 0.5) sets how strongly the generated music follows the prompt; omit it unless you want stricter or looser prompt adherence. Free.

✅

video_to_video_sfx(video_path? | video_url?, prompt?, segments?, output_directory?)

Generate SFX for a video and return a new .mp4 with them muxed in. Max video duration 480s (8 min).

✅

video_to_sound(video_path? | video_url?, music_prompt?, sfx_prompt?, segments?, preserve_speech?, ducking?, output_format?, variants_num?, output_directory?)

Generate music and SFX for a video in one call and save the mixed audio track. One charge instead of two, with the two layers balanced by the backend. ducking (default false) brings the source video's own speech into the mix and dips the music under it — leave it off and the result is the generated music and effects alone, with no music_processed stem. output_format (wav default, m4a, or mp3 at 320 kbps) sets the combined track's container; the music and SFX stems keep their native formats. Max video duration 480s (8 min). variants_num (1–10, default 1) saves one mixed track per variant.

✅

video_to_video_sound(video_path? | video_url?, music_prompt?, sfx_prompt?, segments?, keep_original_sound?, preserve_speech?, ducking?, variants_num?, output_directory?)

Like video_to_sound, but returns a new .mp4 with the mixed soundtrack muxed in. By default the result's audio is the generated music and effects alone — the source's own audio is removed, so the result also carries no music_processed stem. Pass keep_original_sound=true to keep the whole source track (statically mixed; add ducking=true to duck it under the mix instead), or preserve_speech=true for the isolated speech only. keep_original_sound is accepted only here, not by video_to_sound. Max video duration 480s (8 min). variants_num (1–10, default 1) saves one .mp4 per variant.

✅

dubbing(video_path? | video_url?, languages?, ducking?, lipsync?, output_directory?)

Dub a video into other languages and save one dubbed .mp4 per language. languages is a list of codes (en, zh_cn, ja, ko, pt, pt_br, es, es_419, de, fr, it, ru, th, ar, tr, vi, id); omit it for the default ["zh_cn", "es", "fr"]. pt_br is Brazilian Portuguese and es_419 Latin American Spanish; plain pt and es stay unqualified, as does ar. video_url must be https — the dubbing pipeline fetches the source itself. lipsync defaults to true: the speaker's mouth is re-rendered to match the dubbed speech. Set lipsync=false to leave the picture completely untouched instead — the video comes back at its original resolution and frame rate rather than re-rendered, and only the audio is replaced, so the mouths keep moving to the original language; useful for footage with no on-camera speaker. Max video duration 300s (5 min). Billed per language, with no free trial.

✅

analyze_video(video_path? | video_url?, prompt?, variants_num?)

Analyze a video and return a creative brief for scoring it — a time-aligned segments plan plus one ready-to-use generation prompt per variation. Generates nothing and writes no file: the brief comes back inline as JSON, to feed straight into video_to_music, video_to_sfx, video_to_sound or their video-to-video counterparts. Use it when you do not yet know what the video should sound like. Max video duration 360s (6 min); variants_num is 1–5 (default 1) and is billed per brief, with a 10-second billing floor.

✅

audio_ducking(voice_path? | voice_url?, music_path? | music_url?, output_directory?)

Duck a music bed under a voice track. The voice input may be a video — the ducked mix is muxed back into a new .mp4. Each input max 360s (6 min); subject to the account's upload-size cap.

✅

get_sfx_task(task_id, output_directory?)

Check an SFX, audio-ducking, video-to-video, video-to-sound, dubbing, video-analysis, or async video-to-music task and return its result — recovery for timed-out text_to_sfx, video_to_sfx, audio_ducking, video_to_video_music, video_to_video_sfx, video_to_sound, video_to_video_sound, dubbing, analyze_video, and video_to_music(preserve_speech=true) calls. An analyze_video task has no file to download, so its brief comes back inline; everything else is saved to disk.

❌

get_account_services()

List available services, limits, and the free-trial allowance left per service.

❌

get_usage(days=30)

Show usage summary + per-day breakdown.

❌

play_audio(input_file_path)

Play a local audio file.

❌

Tools marked ✅ make API calls that incur charges on your Sonilo account.

Free trial: self-serve accounts start with a few free runs per service — no card required. get_account_services() reports what is left as trial[service] = {granted, used, remaining}; check it before calling a ✅ tool so you can warn the user instead of failing on them. When a service's remaining hits 0, calls to it fail with trial_exhausted until a payment method is added. Dubbing has no free runs and bills from the first call. Accounts without a free-trial allowance simply have no trial key.

Optional: if ffprobe (part of FFmpeg) is installed, video_to_music checks a video's duration locally and rejects anything over 360s before uploading. video_to_sfx performs the same local check with its 180s cap. audio_ducking does the same for both of its inputs against its 360s cap. Without it, the same limits are still enforced by the backend.

Sound effects and ducking run as tasks

The music tools stream their result and finish in one call — with one exception: video_to_music(preserve_speech=true) submits a task and polls it internally instead, because keeping the source speech is only available in the backend's async mode. You still get the saved file paths back from a single call; you just don't see the task, and — like the SFX tools — it uses the same get_sfx_task recovery path if the call times out. The SFX tools submit a task, then poll it until it completes — text_to_sfx and video_to_sfx do this for you and return the saved file paths, so you normally never see the task. audio_ducking uses the same submit-then-poll flow and the same get_sfx_task recovery path.

If a call times out, the generation keeps running (and is already charged). The error message carries the task id, and get_sfx_task("<id>") retrieves the result once it's ready. The task id is also printed to stderr the moment a task is submitted, so it survives even a cancelled call. get_sfx_task is safe to call repeatedly: if the file is already on disk it reports that instead of downloading a second copy.

Output Format

Music is saved as .m4a (AAC in MP4 container). File names use the title returned by the backend (slugified), or a sonilo-<timestamp>.m4a fallback. When multiple parallel streams are returned, a -<index> suffix is appended.

video_to_music(preserve_speech=true) saves up to three kinds of file, each labeled in the returned text: the generated music audio (same naming as above, based on prompt or falling back to music-<first 8 chars of the task id>), the preserved speech stem as <base>-vocals.<ext>, and the mux — speech and music already mixed together, the ready-to-use combined result — as <base>-mux.<ext> (or <base>-mux-<index>.<ext> for multiple streams). The speech stem and mux extensions come from the backend's reported content_type (typically .m4a).

Sound effects are saved in the requested audio_format — wav, mp3, flac, or aac (the default, written as .m4a); video_to_sfx saves audio only, not the source video.

Combined sound (video_to_sound / video_to_video_sound) is saved as a single file: a .wav for video_to_sound, a .mp4 for video_to_video_sound. The name comes from music_prompt, falling back to sfx_prompt and then to sound-<first 8 chars of the task id> / v2v-sound-<first 8 chars of the task id>. The separate music and SFX stems stay on the backend — only the mixed result is downloaded.

Multiple variants (variants_num > 1 on text_to_music, video_to_music, video_to_video_music, video_to_sound, video_to_video_sound) save one file per variant instead of one, suffixed -0, -1, … in request order (e.g. <base>-0.m4a, <base>-1.m4a). For the music tools, each variant is its own creative direction and the returned text names it when the backend provides a title. Cost scales linearly with variants_num, and any value above 1 is billed in full even on a free-trial account. A timed-out multi-variant call recovers all of its variants through get_sfx_task, the same as a single-variant one.

Stems (stems=true on text_to_music / video_to_music) save four extra files per generated stream — <base>-stems-drums.<ext>, -stems-bass, -stems-vocals, -stems-other (with the variant index folded in as <base>-stems-<index>-<name>.<ext> when variants_num > 1) — alongside the untouched full track. Separation is free and best-effort: it typically adds 2–6 minutes (the call waits up to 40), and when it fails or is skipped the result carries a stems_error note instead of (or alongside a partial set of) stem files, while the music itself is unaffected and fully delivered.

Dubbing (dubbing) is saved as one .mp4 per requested language, named dubbing-<first 8 chars of the task id>.<language>.mp4 — there is no prompt to name the files after. Asking for four languages writes four files and costs four times as much as one. Dubbing polls for at least two hours regardless of TIME_OUT_SECONDS, matching the backend's own ceiling for the job.

File names come from the prompt (slugified, truncated to 80 characters). When there is no prompt to name a file after — video_to_sfx without one, or an SFX/ducking file recovered via get_sfx_task — the name is sfx-<first 8 chars of the task id> instead. A video_to_music(preserve_speech=true) task recovered via get_sfx_task is named music-<first 8 chars of the task id> instead (get_sfx_task detects the music envelope shape and saves audio/vocals/mux the same way as a direct video_to_music call). Existing files are never overwritten: a -1, -2, … suffix is added instead.

Ducking results are saved as a single file: a .wav, or a .mp4 when the voice input was a video (the ducked mix is muxed back into it). The file name is the voice input's name plus -ducked (e.g. interview.mp4 → interview-ducked.mp4), falling back to ducked-<first 8 chars of the task id> when there is no usable name. A ducking result recovered via get_sfx_task is named sfx-<first 8 chars of the task id> instead, since that tool has no voice file name to work from.

Common Errors

Message

What to do

SONILO_API_KEY not set and no stored credential found

Run sonilo login, or set SONILO_API_KEY in the server's config.

Invalid SONILO_API_KEY

Verify the key at https://platform.sonilo.com/dashboard/api-keys. If you signed in with the CLI, the key may have expired (90 days) or been revoked — run sonilo login again.

Insufficient minutes / Credit limit exceeded

Top up at https://platform.sonilo.com/dashboard/billing.

You've used your N free trial calls for <service>

That service's free trial is spent. Add a payment method at https://platform.sonilo.com/dashboard/billing — retrying can't help. get_account_services shows what is left on the other services.

Rate limit exceeded: your account allows N requests per minute

Calls are going out too fast. The counter runs on a fixed 60-second window and rejected calls count toward it too, so wait the window out instead of retrying inside it. get_account_services reports your rpm_limit; email info@sonilo.com to raise it.

Too many concurrent generations: N of N in progress

Every generation slot is busy. Waiting alone does not free one — a running generation has to finish first. get_account_services reports your concurrency_limit; email info@sonilo.com to raise it.

Generation timed out (music, text_to_music/video_to_music without preserve_speech)

Raise TIME_OUT_SECONDS. Check get_usage to confirm whether the backend completed and charged.

Timed out … waiting for task <id> (SFX, ducking, or video_to_music(preserve_speech=true))

The generation is still running. Call get_sfx_task("<id>") to retrieve the result — nothing is lost, including for a timed-out preserve_speech music task (get_sfx_task recognizes its result shape and saves audio/vocals/mux the same way video_to_music itself would).

Task not found

The task id doesn't exist, or belongs to a purely streaming generation (text_to_music, or video_to_music without preserve_speech), which isn't pollable. Check the id.

Available Tools

9 tools
audio_duckingA

Duck a music bed under a voice track: Sonilo lowers the music wherever the voice is speaking and lifts it back in the gaps, then returns the mixed result. The voice input may be a video — its audio track is used as the voice, and the ducked mix is muxed back into a new video.

⚠️ COST WARNING: This tool makes an API call to Sonilo which may incur charges. Only use when explicitly requested by the user.

Args: voice_path (str, optional): Absolute local path, or relative to SONILO_MCP_BASE_PATH. Audio (.wav/.mp3/.m4a/.aac/.ogg/.flac) or video (.mp4/.mov/.avi/.wmv/.webm/.mkv). voice_url (str, optional): HTTPS URL to the voice audio/video. music_path (str, optional): Absolute local path, or relative to SONILO_MCP_BASE_PATH. Audio only. music_url (str, optional): HTTPS URL to the music audio. output_directory (str, optional): Where to save the result. Defaults to SONILO_MCP_BASE_PATH.

Exactly one of voice_path/voice_url, and exactly one of music_path/music_url, must be provided. A local file and a URL may be mixed across the two inputs. Each input is capped at 360 seconds (6 minutes) and by the account's upload-size limit (typically 300 MB).

Returns: TextContent with the absolute path of the saved file: a .wav, or a .mp4 when the voice input was a video. If the call times out, the error message includes the task_id — recover the result later with get_sfx_task.

ParametersJSON Schema
NameRequiredDescriptionDefault
music_urlNo
voice_urlNo
music_pathNo
voice_pathNo
output_directoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses behavior: it lowers/lifts music based on voice, handles video input, and describes error recovery via task_id. It also mentions cost implications, adding transparency.

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?

The description is well-structured with clear sections (overview, cost warning, args, returns). It is slightly verbose but every sentence adds value, earning a high score for clarity.

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?

Given the tool's complexity (5 parameters, no required, output schema exists), the description covers all necessary aspects: input formats, constraints, output, and error handling. It is complete for an AI agent to use correctly.

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

Parameters5/5

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

Despite 0% schema description coverage, the description thoroughly explains each parameter (path vs URL, file types, constraints) and the mutual exclusivity rules, compensating fully for the schema gap.

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 clearly states the tool's purpose: 'Duck a music bed under a voice track' and explains the process. It distinguishes from sibling tools (e.g., text_to_music, text_to_sfx) by focusing specifically on audio ducking.

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?

The description includes a cost warning and states 'Only use when explicitly requested by the user.' It also specifies input constraints (exactly one of voice_path/voice_url, etc.), providing clear usage context. However, it does not explicitly contrast with sibling tools.

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

get_account_servicesA

Get the authenticated account's available Sonilo services, rate limits, concurrency limit, discount factor, and max video upload size. Use this to discover what generation endpoints are available before calling them.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the return data (services, rate limits, concurrency, discount, max upload size) and implies read-only behavior. There is no mention of authentication or side effects, but for a simple GET-like tool this is adequate.

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?

Two sentences, no redundancy, front-loaded with the main action. Every word adds value.

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?

The tool has no parameters and no output schema, but the description fully captures its purpose and output. It is complete for a simple informational endpoint.

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?

The tool has zero parameters and the schema coverage is 100%. The description adds no parameter-specific information because none is needed. Baseline for zero-parameter tools is 4.

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 uses a specific verb 'Get' and clearly identifies the resource 'authenticated account's available Sonilo services'. It lists specific data items (rate limits, concurrency limit, etc.) and the sibling tools are all generation tools, so this info tool is well-distinguished.

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?

The description explicitly states 'Use this to discover what generation endpoints are available before calling them', providing clear when-to-use context. It does not mention when not to use or alternatives, but the purpose is sufficiently clear for a self-contained info tool.

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

get_sfx_taskA

Check a sound-effects or audio-ducking generation task and, if finished, download its result file(s). Use this to recover a result when text_to_sfx, video_to_sfx, or audio_ducking timed out — their error message contains the task_id. Does not poll: a single status check per call. This tool itself never charges.

Args: task_id (str): The task id returned in the timeout message. output_directory (str, optional): Where to save result files. Defaults to SONILO_MCP_BASE_PATH.

Returns: Still processing -> a status message; try again later. Succeeded -> the saved file path(s): audio, plus video for video_to_sfx tasks; a single .wav or .mp4 for audio_ducking tasks. Failed -> an error including whether the charge was refunded.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYes
output_directoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: it does not poll, never charges, and details all possible return states (still processing, succeeded, failed including refund info). No contradictions exist.

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?

The description is about 120 words, uses a clear structure with separate sections for args and returns, and avoids redundancy. A slight reduction in wording could improve conciseness without losing clarity.

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?

Given the tool's complexity (2 params, no enums, no nested objects, output schema), the description covers all necessary aspects: purpose, usage trigger, parameter meaning, return behavior, and charging policy. It is fully self-contained.

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?

Despite 0% schema coverage, the description adds meaning: task_id is from the timeout message, output_directory is optional and defaults to SONILO_MCP_BASE_PATH. This provides necessary context beyond the schema's type definitions.

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 clearly states the tool checks and downloads results for audio generation tasks, naming the specific source tools (text_to_sfx, video_to_sfx, audio_ducking). It distinguishes itself as the retrieval mechanism for their timeouts, which is distinct from the sibling generation tools.

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?

The description explains exactly when to use the tool: to recover a result when a generation task timed out, and mentions that it does not poll (single call per status). It does not explicitly list alternatives for retrieving results, but the context makes the intended use clear.

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

get_usageA

Get the authenticated account's usage summary and per-day breakdown. Useful for cost reconciliation and tracking generation history.

Args: days (int, optional): Lookback window in days, 1–365. Defaults to 30.

ParametersJSON Schema
NameRequiredDescriptionDefault
daysNo

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full burden. The term 'Get' implies a read-only operation, but no further behavioral details (e.g., authentication requirements, rate limits, side effects) are disclosed. Basic purpose is clear, but behavioral context is minimal.

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?

The description is concise: a single sentence stating the purpose, followed by a structured Args section. No wasted words. The most important information is front-loaded.

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?

Given a single optional parameter, no output schema, and no annotations, the description covers the parameter well. It lacks detail about the return format (e.g., fields in the usage summary), but the core functionality is sufficiently described for an agent to use the tool.

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

Parameters5/5

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

Schema description coverage is 0%, so the description compensates well. It explains the 'days' parameter with its type (int), optionality, default (30), and valid range (1–365). This adds significant meaning beyond the schema's type and default fields.

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 clearly states the tool retrieves the authenticated account's usage summary with a per-day breakdown. The verb 'get' and noun 'usage summary' are specific. Sibling tool names (e.g., audio_ducking, text_to_sfx) are unrelated to usage data, so this tool is well-differentiated.

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?

The description provides explicit context by stating the tool is 'useful for cost reconciliation and tracking generation history.' While it doesn't list when not to use this tool or alternatives, the siblings are functionally distinct, making the use case clear.

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

play_audioA

Play a local audio file through the system's default output device. Supports WAV, MP3, M4A, AAC, OGG, FLAC.

Args: input_file_path (str): Absolute path or relative to SONILO_MCP_BASE_PATH.

Returns: Success message including the played path.

ParametersJSON Schema
NameRequiredDescriptionDefault
input_file_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
textYes
typeYes
_metaNo
annotationsNo

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses the action and supported formats but omits important behavioral traits like error handling, device availability, or path validation. The return success message is mentioned but not detailed.

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?

The description is very concise with two short sentences and a bullet list of formats. It is front-loaded with the core action and quickly provides essential details without redundancy.

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?

For a simple tool with one parameter, the description is mostly complete. It covers the action, path semantics, formats, and return value. Some minor gaps like error conditions exist, but the tool is straightforward.

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?

The schema only provides parameter name and type (0% coverage). The description adds value by explaining that the path is absolute or relative to SONILO_MCP_BASE_PATH, and lists supported audio formats, which clarifies parameter usage.

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 clearly states the tool's action 'Play a local audio file' and specifies supported formats. It distinguishes from sibling tools like audio_ducking and text_to_music, making its purpose unambiguous.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or any context for usage beyond basic operation.

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

text_to_musicA

Generate music from a text prompt and save the resulting audio file(s) to a local directory. Generated tracks are fully licensed (music licensed via Shutterstock) and cleared for commercial use on social, brand content, and advertising.

⚠️ COST WARNING: This tool makes an API call to Sonilo which may incur charges. Only use when explicitly requested by the user.

Args: prompt (str): Description of the music to generate (1–1000 chars). duration (int): Length in seconds (1–360). output_directory (str, optional): Absolute path, or relative to SONILO_MCP_BASE_PATH. Defaults to SONILO_MCP_BASE_PATH (~/Desktop unless overridden).

Returns: One TextContent per generated audio stream, each containing the absolute path of the saved .m4a file (AAC in MP4 container).

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYes
durationYes
output_directoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description fully carries the burden. It discloses API call cost, local file saving, licensing for commercial use, and return format. This provides substantial behavioral insight for an agent.

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?

The description is concise yet informative, starting with the core action and then covering parameters and warnings. The cost warning is a separate line with emoji for visibility. No superfluous text.

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?

Given the tool's complexity, the description covers the basic workflow, inputs, outputs, and important context (cost, licensing). It lacks error handling details but is sufficient for an agent to use the tool 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 0%, but description adds detailed semantics: prompt character limit (1-1000), duration range (1-360 seconds), and output_directory defaults and path behavior. This greatly enriches the bare schema.

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

Purpose4/5

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

The description clearly states 'Generate music from a text prompt', specifying the action and resource. However, it does not explicitly differentiate from sibling tools like text_to_sfx, though the licensing and 'music' keyword imply distinct purpose.

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

Usage Guidelines3/5

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

The description includes a cost warning and instructs 'Only use when explicitly requested by the user', which gives usage context. However, it lacks explicit guidance on when not to use this tool or when to prefer alternatives like text_to_sfx.

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

text_to_sfxA

Generate a sound effect from a text prompt and save the audio file to a local directory. Generation is asynchronous on the backend; this tool waits for completion (typically well under the timeout) and returns the saved file path.

⚠️ COST WARNING: This tool makes an API call to Sonilo which may incur charges. Only use when explicitly requested by the user.

Args: prompt (str): Description of the sound effect (1–2000 chars). duration (int): Length in seconds (1–180). audio_format (str, optional): One of wav, mp3, aac, flac. Defaults to aac (.m4a file). output_directory (str, optional): Absolute path, or relative to SONILO_MCP_BASE_PATH. Defaults to SONILO_MCP_BASE_PATH (~/Desktop unless overridden).

Returns: TextContent with the absolute path of the saved audio file. If the call times out, the error message includes the task_id — recover the result later with get_sfx_task.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYes
durationYes
audio_formatNo
output_directoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description fully discloses async behavior, potential timeout, cost implication, and return format. It also mentions error recovery with task_id. This is thorough for a mutation-like tool.

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?

The description is well-structured with a clear first sentence, a cost warning, and a parameter list. It is concise enough, though the parameter descriptions could be slightly more compact.

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?

Given 4 parameters, no annotations, and an output schema described, the description covers usage, parameter details, async behavior, and recovery. Sibling tools provide context. No significant gaps remain.

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 0%, so the description compensates by explaining each parameter: prompt character limit, duration range, audio_format options with default, and output_directory defaults. It adds constraints beyond the schema.

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 clearly states the tool generates a sound effect from a text prompt and saves the audio file. It uses a specific verb ('Generate') and resource ('sound effect'), and distinguishes from siblings like text_to_music and video_to_sfx.

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?

The description provides a cost warning and advises using only when explicitly requested. It explains async nature and recovery via get_sfx_task. However, it does not explicitly contrast with sibling tools or state when not to use it beyond cost.

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

video_to_musicA

Generate an original score for a video: Sonilo analyzes the video's pacing, motion, and emotion, aligns transitions and beat drops to its cut points, and matches the video's duration exactly. Provide either a local video file path or a publicly accessible video URL. Generated tracks are fully licensed (music licensed via Shutterstock) and cleared for commercial use on social, brand content, and advertising.

⚠️ COST WARNING: This tool makes an API call to Sonilo which may incur charges. Only use when explicitly requested by the user.

Args: video_path (str, optional): Absolute local path, or relative to SONILO_MCP_BASE_PATH. Supports .mp4/.mov/.avi/.wmv/.webm/.mkv. Subject to the account's max upload size (typically 300 MB). Maximum video duration is 360 seconds (6 minutes). video_url (str, optional): HTTPS URL to a video file. prompt (str, optional): Style hint for the generated music. output_directory (str, optional): Where to save the resulting audio file(s). Defaults to SONILO_MCP_BASE_PATH.

Exactly one of video_path and video_url must be provided.

Returns: One TextContent per generated audio stream.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptNo
video_urlNo
video_pathNo
output_directoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully covers behavioral traits: API call cost, file format support, size/duration limits, licensing clearance, return type, and default output directory.

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?

Well-structured with clear sections (Args, Returns) and cost warning upfront. Slightly long but no redundant sentences; all information serves a purpose.

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?

Given 4 optional parameters with mutual exclusion, an output schema, and moderate complexity, the description fully covers constraints, formats, licensing, and output, leaving no critical gaps.

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

Parameters5/5

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

Schema coverage is 0%, but the description adds detailed semantics for all four parameters: path details, URL requirement, style hint for prompt, default for output_directory. Also specifies that exactly one of video_path/video_url is required.

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 clearly states the tool generates an original score for a video, explaining how Sonilo analyzes pacing, motion, and emotion. It differentiates from sibling tools like text_to_music by focusing on video input.

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?

Explicitly states to use only when explicitly requested by the user due to cost. Provides mutual exclusivity rule for video_path/video_url. However, no direct comparison to alternatives like text_to_sfx.

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

video_to_sfxA

Generate sound effects for a video: Sonilo analyzes the video and creates matching SFX. Returns the generated sound-effects audio file. Provide either a local video file path or a publicly accessible video URL. Generation is asynchronous on the backend; this tool waits for completion and returns the saved file paths.

⚠️ COST WARNING: This tool makes an API call to Sonilo which may incur charges. Only use when explicitly requested by the user.

Args: video_path (str, optional): Absolute local path, or relative to SONILO_MCP_BASE_PATH. Supports .mp4/.mov/.webm/.m4v/.gif (gif must be animated). Subject to the account's max upload size (typically 300 MB). Maximum video duration is 180 seconds (3 minutes). video_url (str, optional): HTTPS URL to a video file. prompt (str, optional): Overall description of the desired sound effects (max 2000 chars). segments (list, optional): Per-segment SFX descriptions, each {"start": float, "end": float, "prompt": str}. Backend rules: first start must be 0; segments must be contiguous (each end == next start); every end > start; every prompt non-empty (max 200 chars); last end must not exceed the video duration; max 30 segments. Invalid segments are rejected before any charge. audio_format (str, optional): One of wav, mp3, aac, flac. Defaults to aac (.m4a file). output_directory (str, optional): Where to save the resulting files. Defaults to SONILO_MCP_BASE_PATH.

Exactly one of video_path and video_url must be provided.

Returns: One TextContent: the saved audio file path. If the call times out, the error message includes the task_id — recover with get_sfx_task.

ParametersJSON Schema
NameRequiredDescriptionDefault
promptNo
segmentsNo
video_urlNo
video_pathNo
audio_formatNo
output_directoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses async backend processing, cost implications, file format/limits, segment validation rules, and error recovery via get_sfx_task. Could mention authentication or file lifecycle but sufficient.

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?

Well-structured with intro, cost warning, parameter details, and return info. Each sentence adds value, though slightly verbose. Front-loaded with purpose.

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?

Covers all 6 parameters with constraints, mutual exclusivity, async nature, error recovery. Does not specify output file persistence, but output schema exists. Adequate for the tool's complexity.

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

Parameters5/5

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

Schema coverage is 0%, so the description must add meaning. It thoroughly explains each parameter: video_path/video_url constraints, prompt length, segments structure and validation, audio_format options, output_directory default. Adds significant value beyond the bare schema.

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 clearly states 'Generate sound effects for a video: Sonilo analyzes the video and creates matching SFX'. It distinguishes this tool from siblings like text_to_sfx or video_to_music by specifying it takes video input and produces sound effects.

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?

Provides explicit guidance: 'Provide either a local video file path or a publicly accessible video URL' and 'Exactly one of video_path and video_url must be provided'. Also includes a cost warning and notes asynchronous behavior. However, it does not explicitly differentiate from sibling tools like text_to_sfx.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 9 tool updatesv0.4.0
    • First observedaudio_ducking
    • First observedget_account_services
    • First observedget_sfx_task
    • First observedget_usage
    • First observedplay_audio
    • First observedtext_to_music
    • First observedtext_to_sfx
    • First observedvideo_to_music
    • First observedvideo_to_sfx
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct operation: audio_ducking mixes voice and music, text/music/sfx generation are separate, video-to-music/sfx are different from text versions, account info and usage are distinct, playback is unique. No overlapping purposes.

Naming Consistency4/5

Tool names follow a consistent snake_case pattern with verb_noun (e.g., get_account_services) or source_to_target (e.g., text_to_music). The only minor deviation is audio_ducking (gerund form) instead of duck_audio, but it's still clear and fits the naming style.

Tool Count5/5

9 tools cover a well-scoped domain: audio/video generation, mixing, playback, and account management. The count is appropriate for the complexity, with each tool earning its place.

Completeness4/5

The tool surface covers generation (text/video to music/sfx), ducking, playback, and account management. Minor gaps include lack of a cancel-task tool, but the core workflows are complete and well-supported.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sonilo-ai/sonilo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server