AI 기반 이미지 생성 및 텍스트-음성 변환 기능을 위한 Minimax API 통합을 통한 MCP(모델 컨텍스트 프로토콜) 서버 구현.
이미지 생성 : Minimax의 image-01 모델을 사용하여 텍스트 프롬프트를 기반으로 고품질 이미지를 생성합니다.
텍스트 음성 변환(TTS) : 다양한 음성 옵션, 감정 및 오디오 형식을 사용하여 텍스트를 자연스러운 음성으로 변환합니다.
간편한 통합 : Windsurf 편집기와 MCP 서버로 원활하게 통합됩니다.
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
두 편집기 모두 동일한 구성 형식을 사용합니다.
지엑스피1
텍스트 프롬프트를 기반으로 이미지 생성:
// 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)
MIT
기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.
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