Una implementación de servidor de Protocolo de contexto de modelo (MCP) con integración de API Minimax para generación de imágenes impulsada por IA y funcionalidad de texto a voz.
Generación de imágenes : genere imágenes de alta calidad basadas en indicaciones de texto utilizando el modelo image-01 de Minimax
Texto a voz (TTS) : convierte texto en voz con sonido natural con diversas opciones de voz, emociones y formatos de audio.
Fácil integración : se integra perfectamente con el editor Windsurf como servidor MCP
Related MCP server: @monsoft/mcp-fal-ai
Node.js 16 o superior
Una clave API de Minimax (obtenida en la Plataforma Minimax )
ID de grupo Minimax para la funcionalidad TTS
Cree o actualice su archivo de configuración MCP:
Para Windsurf: ~/.codeium/windsurf/mcp_config.json
Para el cursor: ~/.cursor/config/mcp_config.json
Ambos editores utilizan el mismo formato de configuración:
{
"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"
}
}
}
}Generar imágenes basadas en indicaciones de texto:
// 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
}Parámetros:
prompt (obligatorio): Descripción de la imagen a generar
outputFile (obligatorio): Ruta absoluta donde guardar el archivo de imagen generado. El directorio debe existir previamente . Al generar varias imágenes (n>1), los archivos se nombrarán con números secuenciales (p. ej., 'imagen-1.jpg', 'imagen-2.jpg').
aspectRatio (opcional): Relación de aspecto de la imagen (predeterminado: "1:1", opciones: "1:1", "16:9", "4:3", "3:2", "2:3", "3:4", "9:16", "21:9")
n (opcional): Número de imágenes a generar (predeterminado: 1, rango: 1-9). Si n > 1, los nombres de los archivos de salida se numeran automáticamente.
subjectReference (opcional): Ruta a un archivo de imagen local o URL pública para referencia de personajes. Si se proporciona, la imagen generada la usará como referencia para la apariencia de los personajes. Formatos compatibles: JPG, JPEG, PNG
Convierte texto a voz con varias opciones de personalización:
// 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 (obligatorio): Texto a convertir a voz (máximo 10.000 caracteres)
outputFile (obligatorio): ruta absoluta para guardar el archivo de audio generado
model (opcional): Versión del modelo a utilizar (predeterminado: "speech-02-hd", opciones: "speech-02-hd", "speech-02-turbo")
speech-02-hd : Modelo de alta definición con excelente similitud de timbre, estabilidad de ritmo y calidad de audio de estudio.
speech-02-turbo : Modelo rápido con excelente rendimiento y baja latencia, capacidades multilingües mejoradas
voiceId (opcional): ID de voz a utilizar (predeterminado: "male-qn-qingse")
speed (opcional): Velocidad del habla (predeterminado: 1.0, rango: 0.5-2.0)
volume (opcional): Volumen de voz (predeterminado: 1.0, rango: 0.1-10.0)
pitch (opcional): tono del habla (predeterminado: 0, rango: -12 a 12)
emotion (opcional): Emoción del discurso (predeterminado: "neutral", opciones: "feliz", "triste", "enojado", "temeroso", "disgustado", "sorprendido", "neutral")
timberWeights (opcional): configuración de mezcla de voces, permite mezclar hasta 4 voces diferentes con pesos
"timberWeights": [
{ "voice_id": "male-qn-qingse", "weight": 70 },
{ "voice_id": "female-shaonv", "weight": 30 }
]format (opcional): Formato de audio (predeterminado: "mp3", opciones: "mp3", "pcm", "flac", "wav")
sampleRate (opcional): frecuencia de muestreo en Hz (predeterminado: 32000, opciones: 8000, 16000, 22050, 24000, 32000, 44100)
bitrate (opcional): tasa de bits para el formato MP3 (predeterminado: 128000, opciones: 32000, 64000, 128000, 256000)
channel (opcional): Número de canales de audio (predeterminado: 1, opciones: 1=mono, 2=estéreo)
latexRead (opcional): si se deben leer fórmulas LaTeX (predeterminado: falso)
pronunciationDict (opcional): Lista de reemplazos de pronunciación
"pronunciationDict": ["处理/(chu3)(li3)", "危险/dangerous"]stream (opcional): si se utilizará el modo de transmisión (predeterminado: falso)
languageBoost (opcional): mejora el reconocimiento de idiomas específicos
Opciones: "Chino", "Chino, Yue", "Inglés", "Árabe", "Ruso", "Español", "Francés", "Portugués", "Alemán", "Turco", "Holandés", "Ucraniano", "Vietnamita", "Indonesio", "Japonés", "Italiano", "Coreano", "Tailandés", "Polaco", "Rumano", "Griego", "Checo", "Finlandés", "Hindi", "Automático"
subtitleEnable (opcional): si se debe habilitar la generación de subtítulos (predeterminado: falso)
Instituto Tecnológico de Massachusetts (MIT)
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
API de Minimax para proporcionar los modelos de IA
Protocolo de contexto de modelo para la especificación 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