Genere imágenes de alta calidad a partir de indicaciones de texto utilizando el modelo Gemini de Google a través del protocolo MCP.
Este servidor MCP permite que cualquier asistente de IA genere imágenes utilizando el modelo de IA Gemini de Google. El servidor gestiona la ingeniería de señales, la conversión de texto a imagen, la generación de nombres de archivo y el almacenamiento local de imágenes, lo que facilita la creación y la gestión de imágenes generadas por IA a través de cualquier cliente MCP.
Related MCP server: Gemini Image Gen MCP Server
Generación de texto a imagen con Gemini 2.0 Flash
Transformación de imagen a imagen basada en indicaciones de texto
Compatibilidad con imágenes basadas en archivos y codificadas en base64
Generación automática e inteligente de nombres de archivos según indicaciones
Traducción automática de indicaciones en idiomas distintos del inglés
Almacenamiento de imágenes local con ruta de salida configurable
Exclusión estricta de texto de las imágenes generadas
Salida de imágenes de alta resolución
Acceso directo tanto a los datos de la imagen como a la ruta del archivo
El servidor proporciona las siguientes herramientas MCP para asistentes de IA:
generate_image_from_textCrea una nueva imagen a partir de una descripción de solicitud de texto.
generate_image_from_text(prompt: str) -> Tuple[bytes, str]Parámetros:
prompt : Descripción de texto de la imagen que desea generar.
Devoluciones:
Una tupla que contiene:
Datos de imagen sin procesar (bytes)
Ruta al archivo de imagen guardado (str)
Este formato de retorno dual permite que los asistentes de IA trabajen con los datos de la imagen directamente o hagan referencia a la ruta del archivo guardado.
Ejemplos:
Generar una imagen de una puesta de sol sobre las montañas.
Crea un cerdo volador fotorrealista en una ciudad de ciencia ficción.
Esta imagen se generó utilizando el mensaje:
"Hi, can you create a 3d rendered image of a pig with wings and a top hat flying over a happy futuristic scifi city with lots of greenery?"
Un cerdo renderizado en 3D con alas y un sombrero de copa volando sobre una ciudad futurista de ciencia ficción llena de vegetación.
Al utilizar este servidor MCP con Claude Desktop Host:
Problemas de rendimiento : El uso de transform_image_from_encoded puede tardar mucho más en procesarse en comparación con otros métodos. Esto se debe a la sobrecarga que supone transferir grandes datos de imagen codificados en base64 mediante el protocolo MCP.
Problemas de resolución de rutas : Puede haber problemas para resolver correctamente las rutas de las imágenes al usar Claude Desktop Host. Es posible que la aplicación host no interprete correctamente las rutas de los archivos devueltos, lo que dificulta el acceso a las imágenes generadas.
Para obtener la mejor experiencia, considere utilizar clientes MCP alternativos o el método transform_image_from_file cuando sea posible.
transform_image_from_encodedTransforma una imagen existente basándose en una solicitud de texto utilizando datos de imagen codificados en base64.
transform_image_from_encoded(encoded_image: str, prompt: str) -> Tuple[bytes, str]Parámetros:
encoded_image : Datos de imagen codificados en Base64 con encabezado de formato (deben tener el formato: "data:image/[format];base64,[data]")
prompt : Descripción de texto de cómo desea transformar la imagen.
Devoluciones:
Una tupla que contiene:
Datos de imagen transformados sin procesar (bytes)
Ruta al archivo de imagen transformada guardada (str)
Ejemplo:
"Añade nieve a este paisaje"
"Cambiar el fondo a una playa"
transform_image_from_fileTransforma un archivo de imagen existente basándose en una solicitud de texto.
transform_image_from_file(image_file_path: str, prompt: str) -> Tuple[bytes, str]Parámetros:
image_file_path : Ruta al archivo de imagen que se va a transformar
prompt : Descripción de texto de cómo desea transformar la imagen.
Devoluciones:
Una tupla que contiene:
Datos de imagen transformados sin procesar (bytes)
Ruta al archivo de imagen transformada guardada (str)
Ejemplos:
"Agrega una llama junto a la persona en esta imagen"
"Haz que esta escena diurna parezca nocturna"
Usando la imagen del cerdo volador creada arriba, aplicamos una transformación con el siguiente mensaje:
"Add a cute baby whale flying alongside the pig"Antes:
Después:
La imagen original del cerdo volador con una linda ballena bebé agregada volando a su lado.
Python 3.11+
Clave API de Google AI (Gemini)
Aplicación host MCP (Claude Desktop App, Cursor u otros clientes compatibles con MCP)
Inicia sesión con tu cuenta de Google
Haga clic en "Crear clave API"
Copie su nueva clave API para usarla en la configuración
Nota: La clave API proporciona una cuota de uso gratuito al mes. Puedes consultar tu uso en Google AI Studio.
Clonar el repositorio:
git clone https://github.com/your-username/gemini-image-generator.git
cd gemini-image-generatorCree un entorno virtual e instale dependencias:
# Using regular venv
python -m venv .venv
source .venv/bin/activate
pip install -e .
# Or using uv
uv venv
source .venv/bin/activate
uv pip install -e .Copie el archivo de entorno de ejemplo y agregue su clave API:
cp .env.example .envEdite el archivo .env para incluir su clave API de Google Gemini y la ruta de salida preferida:
GEMINI_API_KEY="your-gemini-api-key-here"
OUTPUT_IMAGE_PATH="/path/to/save/images"Agregue lo siguiente a su claude_desktop_config.json :
macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"gemini-image-generator": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/gemini-image-generator",
"run",
"server.py"
],
"env": {
"GEMINI_API_KEY": "GEMINI_API_KEY",
"OUTPUT_IMAGE_PATH": "OUTPUT_IMAGE_PATH"
}
}
}
}Una vez instalado y configurado, puedes pedirle a Claude que genere o transforme imágenes mediante indicaciones como:
Generar una imagen de una puesta de sol sobre las montañas.
"Crea una ilustración de un paisaje urbano futurista"
"Haz una imagen de un gato con gafas de sol"
"Transforma esta imagen añadiendo nieve a la escena"
Edita esta foto para que parezca que fue tomada de noche.
"Añade un dragón volando al fondo de esta imagen"
Las imágenes generadas/transformadas se guardarán en la ruta de salida configurada y se mostrarán en Claude. Con los tipos de retorno actualizados, los asistentes de IA también pueden trabajar directamente con los datos de imagen sin necesidad de acceder a los archivos guardados.
Puede probar la aplicación ejecutando el servidor de desarrollo FastMCP:
fastmcp dev server.pyEste comando inicia un servidor de desarrollo local y permite acceder al Inspector de MCP en http://localhost:5173/ . El Inspector de MCP proporciona una práctica interfaz web donde puede probar directamente la herramienta de generación de imágenes sin necesidad de usar Claude ni otro cliente de MCP. Puede introducir indicaciones de texto, ejecutar la herramienta y ver los resultados inmediatamente, lo cual resulta útil para el desarrollo y la depuración.
Licencia MIT
Generate an image based on the given text prompt using Google's Gemini model.
Args:
prompt: User's text prompt describing the desired image to generate
Returns:
Path to the generated image file using Gemini's image generation capabilities
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the model and return type (path to image file) but lacks critical details such as rate limits, authentication requirements, image format, size, quality, or error handling. This is insufficient for a generative AI tool with potential costs and constraints.
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 appropriately sized and front-loaded, starting with the core functionality. The structured sections (Args, Returns) enhance readability, though the second sentence could be more integrated to avoid slight redundancy.
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?
Given the complexity of image generation, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., costs, latency), output specifics (e.g., file format, resolution), and error cases, leaving significant gaps for an AI agent to use the tool effectively.
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?
The schema description coverage is 0%, but the description compensates by explaining the single parameter ('prompt') as 'User's text prompt describing the desired image to generate.' This adds meaningful context beyond the schema's basic type information, clarifying the parameter's role in the generation process.
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 specific action ('Generate an image') and resource ('based on the given text prompt'), using Google's Gemini model. It distinguishes from sibling tools like 'transform_image_from_encoded' and 'transform_image_from_file' by specifying text-based generation rather than transformation from existing images.
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 implies usage for text-to-image generation but does not explicitly state when to use this tool versus alternatives. It mentions the model (Gemini) but provides no guidance on prerequisites, limitations, or scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transform an existing image based on the given text prompt using Google's Gemini model.
Args:
encoded_image: Base64 encoded image data with header. Must be in format:
"data:image/[format];base64,[data]"
Where [format] can be: png, jpeg, jpg, gif, webp, etc.
prompt: Text prompt describing the desired transformation or modifications
Returns:
Path to the transformed image file saved on the server
| Name | Required | Description | Default |
|---|---|---|---|
| encoded_image | Yes | ||
| prompt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool uses Google's Gemini model and that it saves the transformed image on the server, which are useful behavioral traits. However, it doesn't mention rate limits, authentication requirements, file size limits, or potential side effects of the transformation process.
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 efficiently structured with a clear opening sentence stating the purpose, followed by well-organized sections for Args and Returns. Every sentence earns its place by providing essential information without redundancy.
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 2-parameter tool with no annotations and no output schema, the description provides good coverage of purpose, parameters, and basic behavior. It explains what the tool does, how to format inputs, and what to expect as output. The main gap is lack of information about error conditions, performance characteristics, or more detailed behavioral constraints.
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?
With 0% schema description coverage, the description fully compensates by providing detailed semantics for both parameters. It specifies the exact format required for encoded_image (including header format and supported image types) and explains what the prompt parameter should contain. This adds significant value beyond the bare 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's purpose with specific verb ('Transform') and resource ('an existing image'), and distinguishes it from siblings by specifying it uses encoded image data rather than text or file inputs. The mention of Google's Gemini model adds technical specificity.
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 provides clear context about when to use this tool (transforming existing images with encoded data) and implicitly distinguishes it from siblings (generate_image_from_text for text-to-image, transform_image_from_file for file-based transformation). However, it doesn't explicitly state when NOT to use this tool or mention specific prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transform an existing image file based on the given text prompt using Google's Gemini model.
Args:
image_file_path: Path to the image file to be transformed
prompt: Text prompt describing the desired transformation or modifications
Returns:
Path to the transformed image file saved on the server
| Name | Required | Description | Default |
|---|---|---|---|
| image_file_path | Yes | ||
| prompt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool saves the transformed file on the server, which is useful behavioral context. However, it lacks critical details like required permissions, file format limitations, transformation scope, error handling, or whether the operation is reversible/destructive.
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 efficiently structured with a clear purpose statement followed by labeled sections for Args and Returns. Every sentence adds value without redundancy, and information is front-loaded appropriately.
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?
Given no annotations, no output schema, and 2 parameters, the description covers purpose and parameters adequately. However, for a transformation tool with potential complexity (image processing via Gemini), it lacks details about output format, file location specifics, or error cases, leaving gaps in completeness.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters: 'image_file_path' as 'Path to the image file to be transformed' and 'prompt' as 'Text prompt describing the desired transformation or modifications'. This adds essential meaning beyond the bare 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's purpose with specific verb ('Transform') and resource ('existing image file'), and distinguishes it from siblings by specifying it works from a file path rather than text or encoded input. The mention of using Google's Gemini model adds technical specificity.
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 implies usage context by specifying it transforms 'an existing image file' and uses a 'text prompt', which differentiates it from 'generate_image_from_text' (creates new images) and 'transform_image_from_encoded' (uses encoded input). However, it doesn't explicitly state when to choose this tool over alternatives or any prerequisites.
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.
generate_image_from_texttransform_image_from_encodedtransform_image_from_fileScored across 3 tools
The three tools have clearly distinct purposes: generate_image_from_text creates new images from text prompts, while transform_image_from_encoded and transform_image_from_file both transform existing images but differ in input format (base64 encoded vs. file path). The descriptions make these distinctions explicit, eliminating any potential confusion between generation and transformation operations.
All tools follow a consistent verb_noun_from_source naming pattern: generate_image_from_text, transform_image_from_encoded, and transform_image_from_file. This pattern clearly indicates the action (generate/transform), the target (image), and the input source (text/encoded/file), creating a predictable and readable naming convention throughout the toolset.
Three tools is a reasonable count for an image generation server, covering the core operations of generating new images and transforming existing ones. However, the scope feels slightly thin as there are no complementary tools for managing generated images (like listing, deleting, or retrieving metadata), which might limit agent workflows in production scenarios.
The server covers basic image generation and transformation operations well, but has notable gaps in image management. There are no tools for listing generated images, deleting files, retrieving image metadata, or batch operations. While the core generative AI functionality is present, the lack of lifecycle management tools creates potential dead ends for agents working with multiple images over time.
Generate AI images and videos from any compatible MCP client.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
