I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Verify Feature Scope
I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
Problem Description
With STT services, diarization is crucial. There are several ways to achieve this. To test, I wrote an MCP server that connects to an NVIDIA Nemotron 3 Nano omni OpenAI compatible endpoint for transcription and includes pyannote for diarization.
Open-webui can't seem to send files directly, so for my MCP server, I take in the file_id of the uploaded audio file, and then I use an admin API token to retrieve that file from the open-webui files/{id}/content endpoint.
anyways, this caused another issue. The MP3/WAV/MP4 wont be uploaded, or at least a file_id wont be generated unless you have speech to text enabled in the audio settings. This mostly makes sense, because why would you normally want to allow a filetype/extension for something you arent equipped to deal with?
So to get around this, for the approved filetype, I make something up, like audio/thisdoesnotexist, so it never matches, but it still allows the audio file to be uploaded.
Desired Solution you'd like
When adding a new integration, or perhaps a global "extra allowed file extension list", being able to tell open-webui "Hey, I know you dont know what to do with a .mp3 file, but go ahead and upload it anyways..."
Alternatively the "per mcp integration" would have more utility, because then you can tell open-webui "Hey, this file extension can be used for 'this' integration."
Or...
"When this MCP/Integration is enabled, allow this file type, and dont perform other services..."
I.E If I have my transcription MCP Server with diarization enabled, and I have the open-webui STT enabled, the MP3 would not be sent/processed by/to the open-webui STT
Alternatives Considered
The bandaid of specifying a non-existant audio filetype in the STT settings. This works, but it spits out a warning.
I hope that wasnt too confusing!
Additional Context
No response
Originally created by @icsy7867 on GitHub (May 9, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24496
### Check Existing Issues
- [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request.
### Verify Feature Scope
- [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
### Problem Description
With STT services, diarization is crucial. There are several ways to achieve this. To test, I wrote an MCP server that connects to an NVIDIA Nemotron 3 Nano omni OpenAI compatible endpoint for transcription and includes pyannote for diarization.
Open-webui can't seem to send files directly, so for my MCP server, I take in the file_id of the uploaded audio file, and then I use an admin API token to retrieve that file from the open-webui files/{id}/content endpoint.
anyways, this caused another issue. The MP3/WAV/MP4 wont be uploaded, or at least a file_id wont be generated unless you have speech to text enabled in the audio settings. This mostly makes sense, because why would you normally want to allow a filetype/extension for something you arent equipped to deal with?
So to get around this, for the approved filetype, I make something up, like audio/thisdoesnotexist, so it never matches, but it still allows the audio file to be uploaded.
### Desired Solution you'd like
When adding a new integration, or perhaps a global "extra allowed file extension list", being able to tell open-webui "Hey, I know you dont know what to do with a .mp3 file, but go ahead and upload it anyways..."
Alternatively the "per mcp integration" would have more utility, because then you can tell open-webui "Hey, this file extension can be used for 'this' integration."
Or...
"When this MCP/Integration is enabled, allow this file type, and dont perform other services..."
I.E If I have my transcription MCP Server with diarization enabled, and I have the open-webui STT enabled, the MP3 would not be sent/processed by/to the open-webui STT
### Alternatives Considered
The bandaid of specifying a non-existant audio filetype in the STT settings. This works, but it spits out a warning.
I hope that wasnt too confusing!
### Additional Context
_No response_
@owui-terminator[bot] commented on GitHub (May 9, 2026):
🔍Related Issues Found
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
🟣#19740issue: How to pass a file or a file URL when invoking MCP? Related because it is also about Open WebUI's MCP tool interface and the inability to pass files/file URLs into an MCP invocation. Your issue proposes enabling audio files for an MCP integration, which is a narrower version of the same file-passing gap. by gongshaojie12 · bug
🟣#12482feat: Access to Input Audio File Without Transcription Related because it requests access to the raw input audio file without transcription. Your issue specifically needs audio uploads to be available to an MCP-based transcription workflow without Open WebUI processing them first. by SpectreSpect
🟣#17761issue: audio mime types Related because it discusses audio MIME-type handling and supported audio upload formats. Your request depends on Open WebUI accepting audio files for upload even when the built-in STT pipeline is not meant to process them. by rbb-dev · bug
🟣#9227STT API calls do not recognize or accept audio files. Related because it reports audio uploads being rejected as unsupported by the STT endpoint. While older and framed as a bug, it covers the same core upload/format acceptance behavior for audio files that your feature request wants to loosen. by ckraushaar
💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
This comment was generated automatically. React with 👍 if helpful, 👎 if not.
<!-- gh-comment-id:4412706777 -->
@owui-terminator[bot] commented on GitHub (May 9, 2026):
<!-- terminator-bot:related-issues-reply -->
🔍 **Related Issues Found**
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
1. 🟣 [#19740](https://github.com/open-webui/open-webui/issues/19740) **issue: How to pass a file or a file URL when invoking MCP?**
*Related because it is also about Open WebUI's MCP tool interface and the inability to pass files/file URLs into an MCP invocation. Your issue proposes enabling audio files for an MCP integration, which is a narrower version of the same file-passing gap.*
*by gongshaojie12 · `bug`*
2. 🟣 [#12482](https://github.com/open-webui/open-webui/issues/12482) **feat: Access to Input Audio File Without Transcription**
*Related because it requests access to the raw input audio file without transcription. Your issue specifically needs audio uploads to be available to an MCP-based transcription workflow without Open WebUI processing them first.*
*by SpectreSpect*
3. 🟣 [#17761](https://github.com/open-webui/open-webui/issues/17761) **issue: audio mime types**
*Related because it discusses audio MIME-type handling and supported audio upload formats. Your request depends on Open WebUI accepting audio files for upload even when the built-in STT pipeline is not meant to process them.*
*by rbb-dev · `bug`*
4. 🟣 [#9227](https://github.com/open-webui/open-webui/issues/9227) **STT API calls do not recognize or accept audio files.**
*Related because it reports audio uploads being rejected as unsupported by the STT endpoint. While older and framed as a bug, it covers the same core upload/format acceptance behavior for audio files that your feature request wants to loosen.*
*by ckraushaar*
---
💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
*This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
I might try a PR, but it will be a while before I can get to it :D
<!-- gh-comment-id:4412721122 -->
@icsy7867 commented on GitHub (May 9, 2026):
🟣 https://github.com/open-webui/open-webui/issues/12482 feat: Access to Input Audio File Without Transcription
This is related, but I am suggesting a more robust change that can do this for other types.
https://chatgpt.com/share/69ff40ab-cc78-83ea-b56c-7f321a4b6c07
I might try a PR, but it will be a while before I can get to it :D
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @icsy7867 on GitHub (May 9, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24496
Check Existing Issues
Verify Feature Scope
Problem Description
With STT services, diarization is crucial. There are several ways to achieve this. To test, I wrote an MCP server that connects to an NVIDIA Nemotron 3 Nano omni OpenAI compatible endpoint for transcription and includes pyannote for diarization.
Open-webui can't seem to send files directly, so for my MCP server, I take in the file_id of the uploaded audio file, and then I use an admin API token to retrieve that file from the open-webui files/{id}/content endpoint.
anyways, this caused another issue. The MP3/WAV/MP4 wont be uploaded, or at least a file_id wont be generated unless you have speech to text enabled in the audio settings. This mostly makes sense, because why would you normally want to allow a filetype/extension for something you arent equipped to deal with?
So to get around this, for the approved filetype, I make something up, like audio/thisdoesnotexist, so it never matches, but it still allows the audio file to be uploaded.
Desired Solution you'd like
When adding a new integration, or perhaps a global "extra allowed file extension list", being able to tell open-webui "Hey, I know you dont know what to do with a .mp3 file, but go ahead and upload it anyways..."
Alternatively the "per mcp integration" would have more utility, because then you can tell open-webui "Hey, this file extension can be used for 'this' integration."
Or...
"When this MCP/Integration is enabled, allow this file type, and dont perform other services..."
I.E If I have my transcription MCP Server with diarization enabled, and I have the open-webui STT enabled, the MP3 would not be sent/processed by/to the open-webui STT
Alternatives Considered
The bandaid of specifying a non-existant audio filetype in the STT settings. This works, but it spits out a warning.
I hope that wasnt too confusing!
Additional Context
No response
@owui-terminator[bot] commented on GitHub (May 9, 2026):
🔍 Related Issues Found
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
🟣 #19740 issue: How to pass a file or a file URL when invoking MCP?
Related because it is also about Open WebUI's MCP tool interface and the inability to pass files/file URLs into an MCP invocation. Your issue proposes enabling audio files for an MCP integration, which is a narrower version of the same file-passing gap.
by gongshaojie12 ·
bug🟣 #12482 feat: Access to Input Audio File Without Transcription
Related because it requests access to the raw input audio file without transcription. Your issue specifically needs audio uploads to be available to an MCP-based transcription workflow without Open WebUI processing them first.
by SpectreSpect
🟣 #17761 issue: audio mime types
Related because it discusses audio MIME-type handling and supported audio upload formats. Your request depends on Open WebUI accepting audio files for upload even when the built-in STT pipeline is not meant to process them.
by rbb-dev ·
bug🟣 #9227 STT API calls do not recognize or accept audio files.
Related because it reports audio uploads being rejected as unsupported by the STT endpoint. While older and framed as a bug, it covers the same core upload/format acceptance behavior for audio files that your feature request wants to loosen.
by ckraushaar
💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
This comment was generated automatically. React with 👍 if helpful, 👎 if not.
@icsy7867 commented on GitHub (May 9, 2026):
🟣 https://github.com/open-webui/open-webui/issues/12482 feat: Access to Input Audio File Without Transcription
This is related, but I am suggesting a more robust change that can do this for other types.
https://chatgpt.com/share/69ff40ab-cc78-83ea-b56c-7f321a4b6c07
I might try a PR, but it will be a while before I can get to it :D