模型上下文协议 (MCP) 服务器实现与 Minimax API 集成，用于 AI 驱动的图像生成和文本转语音功能。
图像生成：使用 Minimax 的 image-01 模型根据文本提示生成高质量图像
文本转语音 (TTS) ：使用各种语音选项、情感和音频格式将文本转换为自然的语音
轻松集成：作为 MCP 服务器与 Windsurf 编辑器无缝集成
Related MCP server: @monsoft/mcp-fal-ai
Node.js 16 或更高版本
Minimax API 密钥（从Minimax 平台获取）
用于 TTS 功能的 Minimax 组 ID
创建或更新您的 MCP 配置文件：
对于 Windsurf： ~/.codeium/windsurf/mcp_config.json
对于光标： ~/.cursor/config/mcp_config.json
两个编辑器使用相同的配置格式：
{
"mcpServers": {
"minimax-mcp-tools": {
"command": "npx",
"args": [
"minimax-mcp-tools"
],
"env": {
"MINIMAX_API_KEY": "your-minimax-api-key",
"MINIMAX_GROUP_ID": "your-minimax-group-id"
}
}
}
}根据文字提示生成图片：
// Example parameters for image generation
{
"prompt": "A mountain landscape at sunset",
"aspectRatio": "16:9",
"n": 1,
"outputFile": "/absolute/path/to/image.jpg",
"subjectReference": "/path/to/reference.jpg" // Optional: local file or URL
}参数：
prompt （必需）：要生成的图像的描述
outputFile （必需）：保存生成的图像文件的绝对路径。该目录必须已存在。当生成多张图片（n>1）时，文件将以连续的数字命名（例如，“image-1.jpg”、“image-2.jpg”）。
aspectRatio （可选）：图像的纵横比（默认值：“1：1”，选项：“1：1”，“16：9”，“4：3”，“3：2”，“2：3”，“3：4”，“9：16”，“21：9”）
n （可选）：生成的图像数量（默认值：1，范围：1-9）。当 n>1 时，输出文件名将自动编号。
subjectReference （可选）：指向本地图像文件或公共 URL 的路径，用于角色参考。提供后，生成的图像将以此作为角色外观的参考。支持格式：JPG、JPEG、PNG
使用各种自定义选项将文本转换为语音：
// Example parameters for text-to-speech
{
"text": "Hello, this is a test of the text-to-speech functionality.",
"model": "speech-02-hd",
"voiceId": "female-shaonv",
"speed": 1.0,
"volume": 1.0,
"pitch": 0,
"emotion": "happy",
"format": "mp3",
"outputFile": "/absolute/path/to/audio.mp3",
"subtitleEnable": true
}text （必填）：要转换为语音的文本（最多 10,000 个字符）
outputFile （必需）：保存生成的音频文件的绝对路径
model （可选）：要使用的模型版本（默认值：“speech-02-hd”，选项：“speech-02-hd”，“speech-02-turbo”）
speech-02-hd ：高清模型，音色相似度高，节奏稳定性高，音质达到录音棚级别
speech-02-turbo ：性能卓越、延迟低的快速模型，增强了多语言能力
voiceId （可选）：要使用的语音ID（默认值：“male-qn-qingse”）
speed （可选）：语速（默认值：1.0，范围：0.5-2.0）
volume （可选）：语音音量（默认值：1.0，范围：0.1-10.0）
pitch （可选）：语音音调（默认值：0，范围：-12 至 12）
emotion （可选）：演讲的情绪（默认：“中性”，选项：“高兴”，“悲伤”，“愤怒”，“恐惧”，“厌恶”，“惊讶”，“中性”）
timberWeights （可选）：语音混合设置，允许混合最多 4 种不同重量的声音
"timberWeights": [
{ "voice_id": "male-qn-qingse", "weight": 70 },
{ "voice_id": "female-shaonv", "weight": 30 }
]format （可选）：音频格式（默认：“mp3”，选项：“mp3”，“pcm”，“flac”，“wav”）
sampleRate （可选）：采样率（以赫兹为单位）（默认值：32000，选项：8000、16000、22050、24000、32000、44100）
bitrate （可选）：MP3 格式的比特率（默认值：128000，选项：32000、64000、128000、256000）
channel （可选）：音频通道数（默认值：1，选项：1=单声道，2=立体声）
latexRead （可选）：是否读取 LaTeX 公式（默认值：false）
pronunciationDict （可选）：发音替换列表
"pronunciationDict": ["处理/(chu3)(li3)", "危险/dangerous"]stream （可选）：是否使用流模式（默认值：false）
languageBoost （可选）：增强对特定语言的识别
选项：“中文”、“粤语”、“英语”、“阿拉伯语”、“俄语”、“西班牙语”、“法语”、“葡萄牙语”、“德语”、“土耳其语”、“荷兰语”、“乌克兰语”、“越南语”、“印尼语”、“日语”、“意大利语”、“韩语”、“泰语”、“波兰语”、“罗马尼亚语”、“希腊语”、“捷克语”、“芬兰语”、“印地语”、“自动”
subtitleEnable （可选）：是否启用字幕生成（默认值：false）
麻省理工学院
欢迎贡献代码！欢迎提交 Pull 请求。
用于提供 AI 模型的Minimax API
MCP 规范的模型上下文协议
Generate images asynchronously. RECOMMENDED: Submit multiple tasks in batch to saturate rate limits, then call task_barrier once to wait for all completions. Returns task ID only - actual files available after task_barrier.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| outputFile | Yes | Absolute path for generated image | |
| aspectRatio | No | Aspect ratio for the image. Options: 1:1, 16:9, 4:3, 3:2, 2:3, 3:4, 9:16, 21:9 | 1:1 |
| customSize | No | Custom image dimensions (width x height in pixels). Range: 512-2048, must be multiples of 8. Total resolution should stay under 2M pixels. Only supported with image-01 model (cannot be used with style parameter). When both customSize and aspectRatio are set, aspectRatio takes precedence | |
| seed | No | Random seed for reproducible results | |
| subjectReference | No | File path to a portrait image for maintaining facial characteristics in generated images. Only supported with image-01 model (cannot be used with style parameter). Provide a clear frontal face photo for best results. Supports local file paths and URLs. Max 10MB, formats: jpg, jpeg, png | |
| style | No | Art style control settings. Uses image-01-live model which does not support customSize or subjectReference parameters. Cannot be combined with customSize or subjectReference |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It specifies asynchronous generation, that only a task ID is returned, and that files become available after task_barrier. It lacks details on rate limits, idempotency, or cost, but covers the essential behavioral traits for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first gives the primary purpose, the second provides a key recommendation and return behavior. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return value (task ID) and how to get results (task_barrier). It also suggests batch usage. It does not cover error handling or prerequisites, but for a parameter-heavy tool with good schema descriptions, this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86% (high), so the schema already documents most parameters. The description adds no parameter-specific information beyond what is in the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Generate images asynchronously,' clearly stating the verb and resource. It distinguishes itself from sibling tool task_barrier by explaining that it returns only a task ID and that actual files are retrieved via task_barrier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description recommends batch submission to saturate rate limits and using task_barrier for waiting. It provides a clear usage pattern but does not explicitly contrast with submit_speech_generation or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text to speech asynchronously. RECOMMENDED: Submit multiple tasks in batch to saturate rate limits, then call task_barrier once to wait for all completions. Returns task ID only - actual files available after task_barrier.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| outputFile | Yes | Absolute path for audio file | |
| highQuality | No | Use high-quality model (speech-2.8-hd) for audiobooks/premium content. Default: false (uses faster speech-2.8-turbo) | |
| voiceId | No | Voice ID for speech generation. Available voices: male-qn-qingse (青涩青年音色), male-qn-jingying (精英青年音色), male-qn-badao (霸道青年音色), male-qn-daxuesheng (青年大学生音色), female-shaonv (少女音色), female-yujie (御姐音色), female-chengshu (成熟女性音色), female-tianmei (甜美女性音色), presenter_male (男性主持人), presenter_female (女性主持人), audiobook_male_1 (男性有声书1), audiobook_male_2 (男性有声书2), audiobook_female_1 (女性有声书1), audiobook_female_2 (女性有声书2), male-qn-qingse-jingpin (青涩青年音色-beta), male-qn-jingying-jingpin (精英青年音色-beta), male-qn-badao-jingpin (霸道青年音色-beta), male-qn-daxuesheng-jingpin (青年大学生音色-beta), female-shaonv-jingpin (少女音色-beta), female-yujie-jingpin (御姐音色-beta), female-chengshu-jingpin (成熟女性音色-beta), female-tianmei-jingpin (甜美女性音色-beta), clever_boy (聪明男童), cute_boy (可爱男童), lovely_girl (萌萌女童), cartoon_pig (卡通猪小琪), bingjiao_didi (病娇弟弟), junlang_nanyou (俊朗男友), chunzhen_xuedi (纯真学弟), lengdan_xiongzhang (冷淡学长), badao_shaoye (霸道少爷), tianxin_xiaoling (甜心小玲), qiaopi_mengmei (俏皮萌妹), wumei_yujie (妩媚御姐), diadia_xuemei (嗲嗲学妹), danya_xuejie (淡雅学姐), Santa_Claus (Santa Claus), Grinch (Grinch), Rudolph (Rudolph), Arnold (Arnold), Charming_Santa (Charming Santa), Charming_Lady (Charming Lady), Sweet_Girl (Sweet Girl), Cute_Elf (Cute Elf), Attractive_Girl (Attractive Girl), Serene_Woman (Serene Woman) | female-shaonv |
| speed | No | Speech speed multiplier (0.5-2). Higher values = faster speech | |
| volume | No | Audio volume level (0.1-10). Higher values = louder audio | |
| pitch | No | Pitch adjustment in semitones (-12 to 12). Negative = lower pitch, Positive = higher pitch | |
| emotion | No | Emotional tone of the speech. Options: neutral, happy, sad, angry, fearful, disgusted, surprised | neutral |
| format | No | Output audio format. Options: mp3, wav, flac, pcm | mp3 |
| sampleRate | No | Audio sample rate in Hz. Options: 8000, 16000, 22050, 24000, 32000, 44100 | 32000 |
| bitrate | No | Audio bitrate in bps. Options: 64000, 96000, 128000, 160000, 192000, 224000, 256000, 320000 | 128000 |
| languageBoost | No | Enhance recognition for specific languages/dialects. Options: Chinese, Chinese,Yue, English, Arabic, Russian, Spanish, French, Portuguese, German, Turkish, Dutch, Ukrainian, Vietnamese, Indonesian, Japanese, Italian, Korean, Thai, Polish, Romanian, Greek, Czech, Finnish, Hindi, Bulgarian, Danish, Hebrew, Malay, Persian, Slovak, Swedish, Croatian, Filipino, Hungarian, Norwegian, Slovenian, Catalan, Nynorsk, Tamil, Afrikaans, auto. Use "auto" for automatic detection | auto |
| intensity | No | Voice intensity adjustment (-100 to 100). Values closer to -100 make voice more robust, closer to 100 make voice softer | |
| timbre | No | Voice timbre adjustment (-100 to 100). Values closer to -100 make voice more mellow, closer to 100 make voice more crisp | |
| sound_effects | No | Sound effects. Options: spacious_echo (空旷回音), auditorium_echo (礼堂广播), lofi_telephone (电话失真), robotic (机械音). Only one sound effect can be used per request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes async behavior, return value (task ID), and dependency on task_barrier, but lacks details on error handling, auth, or rate limit specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then guidance, then return info. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and async workflow adequately given 15 parameters and no output schema, but could mention voice selection or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 93%, so description adds little beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts text to speech asynchronously, distinguishing it from sibling tools like submit_image_generation and task_barrier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends batching submissions to saturate rate limits and using task_barrier for completion, providing actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for ALL submitted tasks to complete and retrieve results. Essential for batch processing - submit multiple tasks first, then call task_barrier once to collect all results efficiently. Clears completed tasks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description includes a side effect (clears completed tasks) and implies blocking behavior. However, it lacks details on timeouts, error handling, or concurrency, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that efficiently convey purpose, usage, and a behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description covers purpose, usage, and side effects. It is complete enough given the simplicity, though more detail on behavior would elevate it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description does not need to add parameter info, and it is consistent with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for all submitted tasks to complete and retrieves results, using a specific verb-resource combination. It is well-differentiated from sibling submission tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this after submitting multiple tasks for efficient batch processing, providing a clear usage context. It does not mention when not to use or alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.2.0generate_imagegenerate_speechsubmit_image_generationsubmit_speech_generationtask_barrierv1.0.0generate_imagegenerate_speechScored across 3 tools
Each tool has a clearly distinct purpose: image generation, speech generation, and task barrier. No overlap or ambiguity.
The submission tools consistently use 'submit_' prefix, but 'task_barrier' deviates from this pattern, causing minor inconsistency.
3 tools is minimal but covers the core batch submission and collection workflow. Could be expanded with per-task management, but not unreasonably sparse.
Missing common operations like task cancellation, individual status checks, or listing tasks. The surface is limited to batch submission and barrier collection.
MCP server for Qwen Image 3 AI image generation
MCP server for Hailuo (MiniMax) AI video generation
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud