[Bug for MCP&API]: TTS audio has an unwanted end-of-audio "beep" tone on all voices

Basic Information - Models Used

speech-02-hd (or speech-01 if older) voice_id: Chinese (Mandarin)_Unrestrained_Young_Man

Basic Information - Scenario Description

TTS voice messages for AI roleplay (WeChat channel). All generated audio now ends with an unwanted electronic "beep" tone starting ~2026-08-13 01:10 UTC+8. Affects all voices. Regression.

Is this bug known and solvable?

• I have followed the GitHub READMEs for Minimax-MCP and Minimax-MCP-JS.
• I have checked the official Minimax documentation and existing GitHub issues，but found no solution.

Information about environment

• Caller: AI agent on OpenClaw platform (not direct CLI/API)
• Channel integration: openclaw-weixin
• Region: CN (assumed api.minimaxi.com)
• Specific MCP server version: Unknown (managed by platform)
• Specific TTS model: Unknown (not returned in API response)
• Python/OS: not directly accessible (managed by OpenClaw)
• Reproducible: 100% (every call since 2026-08-13 ~01:10 UTC+8)

Trace-ID in the request head

Unable to provide

Description

Bug summary: TTS audio generated by synthesize_speech has an unwanted "beep" tone appended at the end, on all voices, since 2026-08-13 ~01:10 UTC+8. This is a regression — audio generated before that time does not have this issue.
Expected behavior: Audio ends cleanly with the spoken text. No additional tones should be appended.
Actual behavior: A short electronic "beep" / "滴滴滴" tone plays at the end of the audio, after the spoken text finishes. The tone is audible to human ears but not always detectable by automated audio analysis (likely short duration, low energy, or in a frequency band that audio classifiers ignore).
Reproduction:
1.
Call synthesize_speech with any voice_id and any text input
2.
Play the generated mp3 file
3.
Listen to the last 0.5-1 second of the audio
4.
Observe: a short "beep" tone is appended after the spoken text ends
Voices tested (all have the same issue):
Chinese (Mandarin)_Unrestrained_Young_Man
Chinese (Mandarin)_Gentleman
male-qn-badao-jingpin
Parameters tested (no effect on the issue):
pitch: 0, -1, -4
speed: 0.82, 0.85, 0.86, 0.9
Various text inputs (short and long)
First observed: 2026-08-13 ~01:10 UTC+8 Audio generated before this time: clean, no end tone
Caller environment:
AI agent on OpenClaw platform
Channel integration: openclaw-weixin
Region: CN (api.minimaxi.com)
Specific MCP server version: Unknown (managed by platform)
Specific TTS model: Unknown (not returned in API response)
trace_id: Not available (AI agent caller does not surface trace-ids in the response)
Suggested fix: Option A: Remove the end-of-audio tone by default. Option B: Add an opt-out parameter, e.g. disable_end_tone: true.
Impact: Makes TTS unusable for voice message applications where the audio needs to end cleanly. Affects all users relying on MiniMax TTS for natural-sounding voice output.

Start at the synthesize_speech integration and review the MiniMax README and official API documentation, since no repository file or test is named. Reproduce the MP3 output across the listed voices and parameters, comparing audio generated before and after the reported regression date. Done means identifying a repository-controlled cause or documenting that the appended tone is produced upstream.