ChatCut

submit_sound

Destructive

Generate a new sound effect with ElevenLabs and create an audio asset in the project library.

External MCP spend rule: this tool costs ChatCut credits and starts an async generation job. Only call it when the user's request or confirmation clearly covers this exact generation; do not silently create extra variants, longer durations, higher quality, or additional outputs.

Do not use this for ordinary editing SFX that may already exist in ChatCut Sound Effects, such as whoosh, riser, impact, notification, click, ding, censor beep, record scratch, camera shutter, keyboard typing, or reaction sounds. For those, first call browse_library with category:"sound-effects", then place the returned library:sound id with edit_item. Use submit_sound only when the user explicitly asks to generate/original/custom audio, or when browse_library cannot find a suitable existing sound.

This tool does not place or replace timeline items; after the job completes, use track_progress to get the asset id and edit_item to place it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>"
    },
    "name": "submit_sound"
  }
}

Input Schema

Name	Required	Description
`name`	No
`prompt`	Yes	Describe one sound in at most 450 characters (e.g. "Thunder and heavy rain", "Door creaking open").
`projectId`	No	Project for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
`timelineId`	No
`durationSeconds`	No	0.5–30 seconds. Defaults to 4.
`promptInfluence`	No	0–1, default 0.3. Higher = stricter prompt adherence, lower = more model variation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, it discloses that the call spends ChatCut credits, launches an async job, and must not silently expand scope (extra variants, longer durations, higher quality). It also clarifies the tool does not place or replace timeline items and hands off to track_progress and edit_item, which the destructiveHint/openWorldHint annotations alone would not convey.

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 action is front-loaded in the first sentence, followed by cost/scope rules, then the exclusion list, then the hand-off note — a logical order. It is somewhat long and the scope caution is restated twice (spend rule and 'do not silently create extra variants'), costing a bit of tightness.

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 6-param async generation tool with no output schema, it covers cost, async nature, scope limits, disallowed uses, the sibling alternative, and the required follow-up tools for retrieving and placing the asset. An agent has everything needed to decide and to act after the job starts.

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

Parameters3/5

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

Schema coverage is 67%, and the description adds real constraint semantics only indirectly: the ban on silently increasing duration or quality implicitly governs durationSeconds and any quality-like tuning. It adds nothing about name, projectId, timelineId, or promptInfluence, so it only partially compensates for the remaining coverage gap; baseline 3 is appropriate.

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: generate a sound effect via ElevenLabs and create an audio asset in the project library. It is clearly distinguishable from siblings like submit_music, submit_voice, and browse_library by naming the exact generation path and the library-result workflow.

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 an explicit when-not-to-use list (whoosh, riser, impact, notification, click, ding, beep, etc.), names the alternative path (browse_library with category:"sound-effects" then edit_item), and states the escalation condition (explicit request for original/custom audio or library miss). Nothing is left to inference about routing.

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

All ChatCut 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.