Ignix

Generate a sound effect

generate_sound_effect

Create a NEW short sound effect (up to 4 s) from a description and return a WAV file URL with its duration. Not music and not voice. Check list_sound_effects first: it has 75 ready-made effects (whooshes, clicks, pops, impacts, cash register, applause…) that cost nothing. This one spends 15 AI credits per sound, so download it and reuse it instead of asking for the same one twice. SPENDS AI CREDITS ONLY WITH confirm: true. Call it first without confirm: nothing runs and nothing is charged, you get the quote (what it will do and the credits). Tell the user, in your own words, exactly that — including the options you chose, so they can change them — and wait for a clear yes before calling again with the same arguments and confirm: true. One yes covers the plan they approved (e.g. every line of an approved voice-over with the chosen voice); anything new or different needs a new yes.

Input Schema

Name	Required	Description
`confirm`	No	true ONLY after the user said yes to the quote (what it does and the credits). Without it nothing runs and nothing is charged.
`description`	Yes	The sound in a few words (3-160 characters), e.g. "quick whoosh transition" or "soft notification pop".
`workspaceId`	No	Workspace to work on (an id from list_workspaces). Not needed when this connection is tied to one workspace, or when you pass an account: the account's workspace is used.
`idempotencyKey`	No	Optional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.

Output Schema

Name	Required	Description
`url`	No	Public URL of the WAV file. It expires after 7 days: download it into the project.
`mediaType`	No
`durationSec`	No	Exact length of the audio, in seconds.
`confirmToken`	No
`creditsCharged`	No
`creditsRemaining`	No	Credits left this month. null = this organization has no monthly credit cap.
`estimatedCredits`	No
`needsConfirmation`	No	true = this is only the quote: nothing was done or charged.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 22, 2026

addedOutput schema / properties / confirmToken
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / estimatedCredits
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / needsConfirmation

Added value: +{
+  "description": "true = this is only the quote: nothing was done or charged.",
+  "type": "boolean"
+}

removedOutput schema / required

Removed value: -[
-  "url",
-  "durationSec"
-]

First observedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing the 15-credit cost per sound, the two-phase quote/confirm billing model, that a call without confirm charges nothing, and that one approval covers a whole plan while anything new needs a fresh yes. This is exactly the credit/authorization context annotations cannot carry.

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?

Purpose and cost constraint are front-loaded, and nearly every sentence is load-bearing (cost, alternatives, confirm flow). It is on the long side and the 'tell the user in your own words' sentence is slightly verbose, but nothing is redundant.

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?

An output schema exists so return values need not be documented, and the description still notes the WAV URL and duration. Combined with credit cost, confirmation protocol, free-alternative routing, and idempotency guidance, an agent has everything needed to call this safely on the first attempt.

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 100%, so baseline is 3; the description nonetheless adds real meaning to 'confirm' (only true after the user approved the exact quote, must be re-sent with the same arguments) and to the retry semantics around idempotency. It does not add much about description/workspace, but the confirmation contract is materially clarified.

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 (create a new short sound effect, up to 4 s, WAV URL + duration) and explicitly carves out the boundary against siblings: 'Not music and not voice', and contrasts with list_sound_effects. An agent can tell exactly which tool to call without opening the 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?

Gives an explicit when-not and alternative: check list_sound_effects first because it has 75 ready-made effects that cost nothing, and reuse downloaded sounds instead of regenerating. It also spells out the use-time workflow (call without confirm for a quote, then with confirm after user approval), leaving no inference required.

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

All Ignix 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?