AI を活用した画像生成とテキスト読み上げ機能のための Minimax API 統合を備えたモデル コンテキスト プロトコル (MCP) サーバー実装。
画像生成: Minimaxのimage-01モデルを使用して、テキストプロンプトに基づいて高品質の画像を生成します。
テキスト読み上げ（TTS） ：さまざまな音声オプション、感情、オーディオ形式を使用して、テキストを自然な音声に変換します。
簡単な統合: Windsurf エディターを MCP サーバーとしてシームレスに統合します。
Related MCP server: @monsoft/mcp-fal-ai
Node.js 16以上
Minimax APIキー（ Minimax Platformから取得）
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 (オプション): Hz 単位のサンプルレート (デフォルト: 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)
マサチューセッツ工科大学
貢献を歓迎します！お気軽にプルリクエストを送信してください。
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