R3

Change a sound: make a new version of it

r3_sound_update

Change a sound the account owns: overrides {seed, duration, channels} applied to its own recipe, or a whole new recipe (read the current one with r3_sound_read, change it, pass it here; r3_docs_read("SOUND_RECIPES.md") has the format). The sound itself never changes: the change is saved as a new version under the same name (the user's audio list shows the latest), with a new url, and every project and release using an older version keeps it. Give name only to make a separate copy under that name instead. The same recipe as the latest version saves nothing. The answer names the user's projects still on an older version (r3_component_set moves an Audio component's url). An invalid change is refused with the path of the problem. Counts toward the 60 sounds an hour.

Input Schema

Name	Required	Description
`name`	No	Only to make a separate COPY under this name. Default: a new version of the same sound, same name.
`recipe`	No	Or a whole new recipe (format "r3-sound-recipe", version 1).
`audioId`	Yes	The sound to change (the account's own).
`overrides`	No	Changes to its recipe: {seed, duration, channels}.

Output Schema

Name	Required	Description
`url`	Yes
`loop`	Yes
`name`	Yes
`stats`	Yes
`answer`	Yes	This answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
`audioId`	Yes
`version`	Yes
`seamless`	Yes
`warnings`	Yes
`listenUrl`	Yes
`unchanged`	Yes
`durationMs`	Yes
`previousId`	Yes
`previousInUse`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 31, 2026

changedInput schema / properties / name / description

Previous value: -"The new sound's name. Default: the old name with the next number (\"Rotor 2\")."New value: +"Only to make a separate COPY under this name. Default: a new version of the same sound, same name."

addedOutput schema / properties / unchanged
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / version
```
Added value: +{
+  "type": "number"
+}
```

changedOutput schema / required

Previous value: -[
-  "audioId",
-  "name",
-  "url",
-  "listenUrl",
-  "durationMs",
-  "loop",
-  "seamless",
-  "stats",
-  "warnings",
-  "previousId",
-  "previousInUse",
-  "answer"
-]New value: +[
+  "audioId",
+  "name",
+  "url",
+  "listenUrl",
+  "durationMs",
+  "loop",
+  "seamless",
+  "stats",
+  "warnings",
+  "previousId",
+  "version",
+  "unchanged",
+  "previousInUse",
+  "answer"
+]

AddedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare non-read-only, non-idempotent, non-destructive, open-world; the description adds far more: versioning is immutable (older project/release versions keep their copy), the url changes, no-op behavior, quota of 60 sounds per hour, and invalid changes are refused with the offending path. These are operational facts the agent cannot derive from structured fields.

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 action and the two modes, then the versioning consequence, then the copy/edge cases, then quota. Dense parenthetical asides make sentences long, but virtually every clause carries actionable information; only the quota sentence feels tacked on.

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 mutation tool with nested objects, an output schema, and full annotation coverage, the description covers mode selection, side effects, idempotency edge case, error shape, rate limit, and follow-up actions (moving component urls). Nothing an agent needs before calling is missing.

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 the baseline is 3, but the description genuinely adds meaning: `name` is copy-mode only (schema says the same, description makes the consequence explicit), `overrides` mutate the sound's own recipe rather than replacing it, and `recipe` requires the versioned 'r3-sound-recipe' format. Marginal lift beyond the schema, not a rewrite of it.

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 ('Change a sound the account owns') and immediately pins down the two modes: overrides on its own recipe, or a whole new `recipe`. The title reinforces the key distinction from r3_sound_create — the sound identity never changes, only a new version is made.

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?

Explicitly routes the agent: read the current recipe with r3_sound_read, check the format via r3_docs_read("SOUND_RECIPES.md"), pass `name` only to make a separate copy, and use r3_component_set to move a project's Audio component url. It also names the no-op case (same recipe as latest saves nothing), so the agent knows when to skip the call.

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

All R3 tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?