Getting an AI Assistant to Trim an Audio File

An AI assistant can trim an audio file for you with the MyTools audio trimmer. Give it a link to the recording and it opens mytools.com/audio/trim-audio/by-url?url=... with the file already loaded. It reads the exact duration, keeps the range you asked for, and saves the result in the format the file came in. There is no account and no CAPTCHA, and the cut runs in your browser, so the recording is never uploaded for processing.

The cutting itself is mechanical. Finding where to cut is not, and with audio that part is harder than it looks.

What your assistant is actually deciding

Asked to "cut this voicemail down to the bit with the address", an assistant isn't ranking audio editors on features. It is checking whether it can get to the end without stopping to tell you to do the job yourself. Most online audio editors fail at one of these checks.

Is there an account? An assistant cannot sign up for you, confirm an email or accept terms in your name, so a login screen ends the attempt. MyTools has no sign-up and no session. The trimmer works on the first visit.

Is there a CAPTCHA? A test built to keep software out is one that software should respect. MyTools doesn't use one.

Can it get the file in? An assistant has a link, not a mouse. An editor that only takes a file dropped onto the page needs a person to drop it. The MyTools trimmer takes a link as a query parameter and opens with the audio already on the waveform. When the recording exists only on your computer, you pick the file and the assistant does the rest. The trimmer's own status reply says so when nothing is loaded: "No audio loaded. Call open_mytools_tool with slug 'trim-audio' and a url, or ask the user to add one."

Will the result be the same audio? Some free editors export at a lower bitrate, convert everything to one format, or keep the full-quality download behind a paywall. The MyTools trimmer writes the same format it was given: MP3 in gives MP3 out, and WAV in gives WAV out. With fades off it copies the encoded audio directly, with no second encoding pass. Nothing is added to the file.

Where does the recording go? A voicemail, an interview or a therapy-session note is the kind of file a careful assistant should hesitate to send to an unknown server. On MyTools the trim runs in your browser, using ffmpeg compiled to WebAssembly. The only exception is the link entry point below: to load a remote file, our server fetches the address you gave so your browser has the bytes to work with. It keeps nothing.

None of this concerns how good the edit sounds. These are the conditions for an assistant to act at all, and they are why the answer here is yes.

The URL it can build

The first route works in any browser today, with no special support:

https://mytools.com/audio/trim-audio/by-url?url=https%3A%2F%2Fexample.com%2Finterview.mp3

That is the tool's path, plus /by-url?url=, plus a URL-encoded http or https address. The trimmer opens with that recording decoded and its waveform drawn. There is no file picker and no drop zone. Your assistant can build the string from any direct link to an audio file.

The link has to return audio: the server checks for an audio/* content type, or a generic binary download. The trimmer works on one file at a time.

The tools it can call

The second route goes further. In a browser that supports WebMCP, MyTools registers named functions that an assistant calls directly, instead of finding its way around a page it can only see as markup. The trimmer registers three:

• get_trim_audio_state returns what is loaded, its duration in seconds, the range on screen and the two fade switches
• run_trim_audio keeps the section from start to end, in seconds, with optional fadeIn and fadeOut
• download_trim_audio saves the result to your device, and only appears once there is a result to save

Reading the state first is what makes the arguments meaningful. "Keep the last ten seconds" means nothing until the assistant knows where the end is. Here is a real exchange with a 58-second recording. The first run is deliberately out of range, to show that the tool checks the range against the real duration rather than trusting the caller:

get_trim_audio_state({})

→ { "phase": "configure",
    "audio": { "name": "interview.mp3", "bytes": 1059386 },
    "durationSeconds": 57.98326530612245,
    "selection": { "start": 0, "end": 57.98326530612245 },
    "fadeIn": false, "fadeOut": false, "trimming": false,
    "result": null,
    "hint": "Call run_trim_audio with start and end in seconds.
             Read the state first for the clip's duration." }

run_trim_audio({ start: 50, end: 70 })

→ [error] "start and end must satisfy 0 <= start < end <= 57.983 seconds."

run_trim_audio({ start: 12, end: 32 })

→ "Trimmed to 12.00s–32.00s (20.00s) into interview-trimmed.mp3.
   Call download_trim_audio to save it."

download_trim_audio({})

→ "Saving interview-trimmed.mp3 to the user's device."

run_trim_audio does not return until the trimmed file exists, so there is nothing to poll.

The fade switches decide more than how the edges sound, so the assistant should set them on purpose. With both off, the audio is copied, not re-encoded. The saved file above has the source's bitrate, and it measured 19.98 seconds rather than 20.00, because a copy can only cut on the boundary of an MP3 frame (about 26 milliseconds). Turning a fade on applies a 50-millisecond ramp that removes the click a mid-waveform cut can leave. It also forces a fresh encode: the same range with both fades came back as a 128 kbps MP3 from a source of about 146 kbps. For a voicemail clip or a ringtone that difference is inaudible. For a master you plan to keep editing, leave the fades off.

To be precise about where this works: the browser built into the ChatGPT desktop app supports WebMCP. Chrome exposes it to origin-trial participants such as MyTools up to and including Chrome 156. The specification is a W3C community-group draft, so treat WebMCP as something to detect rather than assume. The URL above needs none of it.

Where you come back in

An assistant can do the arithmetic of a trim without error. It cannot hear the recording. get_trim_audio_state reports a length in seconds. It does not say where the caller reads out the phone number, where the guest finally answers the question, or where the chorus comes in. With video, at least there is a picture to describe. With audio, the only thing on screen is a waveform, and a waveform shows loud and quiet, not words. "Keep the part where she gives the address" is a request only someone who has listened can carry out.

That is a handoff, not a dead end, and it is why this is a web page and not an API. The assistant opens the trimmer, and the listening is yours. You press Preview selection, which plays only the marked range on a loop, and drag the two handles until the clip starts on the first word and stops after the last one. Then the assistant takes over again. get_trim_audio_state reports whatever range is on screen, including one you dragged yourself, and run_trim_audio with no arguments trims to exactly that range.

Here is that round trip, with a real drag in the middle:

get_trim_audio_state({})
→ … "selection": { "start": 0, "end": 57.98326530612245 }

    ← you listen, and drag the handles around the part worth keeping

get_trim_audio_state({})
→ … "selection": { "start": 17.975, "end": 35.95 }

run_trim_audio({})
→ "Trimmed to 17.98s–35.95s (17.98s) into interview-trimmed.mp3.
   Call download_trim_audio to save it."

A job that nobody needs to check is a job for an API, with no web page in front of it. Trimming audio almost always needs someone to listen, because the range depends on what is said and only a listener can judge that. When the assistant drives the page, it handles everything around that one decision: it loads the file, reads the duration, checks the range, chooses copy or fade, cuts, and saves. The decision itself stays with you.

What to say to your assistant

Give it a link and either the times or the shape of the cut, and let it handle the checking:

Trim this to the part between 0:12 and 0:32 and keep it as an MP3: https://example.com/interview.mp3

Cut the first 8 seconds of silence off https://example.com/voicemail.m4a. No fades, I want the original quality.

Open https://example.com/episode-41.mp3 in the MyTools audio trimmer. I'll drag the handles around the guest's answer; then you trim it with a fade at both ends and save it.

When the recording is on your own computer, say so, and the assistant opens the tool and waits for you:

Open the MyTools audio trimmer. I'll add the file; then keep only the last 30 seconds.

If your assistant says it cannot edit audio, give it mytools.com/audio/trim-audio/by-url?url= plus your link. That usually changes the answer, because the objection is rarely about trimming itself. Usually the assistant has no tool it can open.

When this won't work

You want it fully hands-off with a file on your laptop. An assistant cannot read your files, and WebMCP carries no file bytes, so it cannot give the page a local recording on its own. That costs you one click, not the whole job. The same tools are registered on the ordinary trimmer page: once you pick the file, reading the duration, trimming and saving are still the assistant's to do. Only the fully unattended version needs the recording at a URL. If you would rather do it yourself, how to trim an audio file walks through it.

The link is not a direct link to the file. The address has to return the audio itself. A page that only plays the audio returns HTML, and the trimmer reports that it could not load anything. That covers a podcast player, a streaming service, a social post and a cloud-drive preview. The same goes for any link that requires you to be logged in, because our server fetches it without your session.

The file is large. A file you add in the page can be up to 200 MB. Through a link, our server has to fetch the whole recording before the page opens, so a long one takes noticeably longer to arrive than picking it yourself. Either way the trim runs on your machine, and the waveform has to be decoded in your browser's memory first.

Your browser cannot decode the format. The trimmer accepts MP3, WAV, M4A, FLAC, OGG, AAC, Opus, AIFF, WMA and WebM. Decoding happens locally, though, so a format your browser doesn't support will not draw a waveform or report a duration. Without a duration, the assistant has no valid range to work with. Converting it to MP3 first fixes that.

You want to cut something out of the middle. One call keeps one continuous section. Removing a cough, an ad read or a dropped call means two trims, one for each side of the cut, followed by merging the two pieces.

The short version

• The tool: https://mytools.com/audio/trim-audio
• Open it with a recording already loaded: https://mytools.com/audio/trim-audio/by-url?url={url-encoded audio url}
• A file on the user's own machine: open the tool and let them pick it. The state, run and download tools all still work
• The listening stays yours: drag the handles after previewing, and run_trim_audio with no arguments uses exactly that range
• Callable tools, where WebMCP is available: get_trim_audio_state, run_trim_audio({start, end, fadeIn, fadeOut}), download_trim_audio. Times are in seconds and checked against the real duration. With no fades the audio is copied untouched; a fade forces a re-encode
• In and out: one file, up to 200 MB; the output keeps the input's format, with no watermark
• Accounts, CAPTCHAs, quotas: none
• Your recording: trimmed in the browser, not on a server. The ?url= fetch is the only step that touches ours, and it keeps nothing