R3

List the audio files on this R3 account

r3_audio_list

Read-onlyIdempotent

List the audio files this R3 account owns, with the URL to use for each one. That URL is exactly what R3ComponentAudio.url takes, so this is how you find a sound the account already has — a footstep, a drum hit, a music bed — and then point an Audio component at it with r3_component_set.

Search by name rather than paging: search: "kick" is matched against every audio file on the account by the server, not against the page you happen to be holding.

You cannot upload an audio file from here — a tool argument is JSON, this server cannot read your disk, and audio is megabytes. A person uploads those in the R3 app. r3_sound_create makes a new sound effect or seamless loop from a recipe (rendered by R3, listed here afterwards); R3's music components (Transport, Beat, Pattern, DrumGrid) synthesise music that stays editable and in tempo.

Input Schema

Name	Required	Description
`limit`	No	How many to return (default 25, max 100).
`cursor`	No	Continue a previous listing: pass the nextCursor it returned, unchanged. Omit for the first page.
`search`	No	Match this text against the file names, on the server. Omit for everything.

Output Schema

Name	Required	Description
`limit`	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.
`audios`	Yes
`search`	Yes
`hasMore`	Yes
`nextCursor`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 15, 2026

addedOutput schema / properties / answer

Added value: +{
+  "description": "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.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "audios",
-  "limit",
-  "search",
-  "hasMore",
-  "nextCursor"
-]New value: +[
+  "audios",
+  "limit",
+  "search",
+  "hasMore",
+  "nextCursor",
+  "answer"
+]

First observedOct 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat that. It adds meaningful context beyond the annotations: the returned URL is directly assignable to R3ComponentAudio.url, search is matched server-side against every file rather than the current page, and uploads are impossible from this tool. It doesn't discuss rate limits or result ordering, so not a 5.

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 purpose and the key URL detail, then follows with search guidance and limitations. Slightly verbose in the upload explanation ('a tool argument is JSON, this server cannot read your disk, and audio is megabytes'), but every paragraph serves a real agent need.

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?

With an output schema present, the description needn't explain return values. It covers the full workflow an agent needs—find by search, get a URL, assign via r3_component_set—and rules out the wrong assumption that this tool can upload. Minor gaps (ordering, pagination mechanics beyond cursor) are already handled by the schema.

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 100%, so limit, cursor, and search are already documented in the schema, including that search matches on the server. The description reinforces search semantics with an example ('kick') and clarifies it isn't page-local, but this is a modest addition over the schema, so 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?

States a specific verb and resource ('List the audio files this R3 account owns') and immediately says what each item carries (the URL usable as R3ComponentAudio.url). It is clearly distinguishable from siblings like r3_sound_create, r3_image_list, and r3_component_set.

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 explicit when-to-use guidance: find a sound the account already has and point an Audio component at it via r3_component_set. It also explains search-vs-paging, states the upload limitation, and names r3_sound_create and R3 music components as the alternatives for making new audio.

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?