MCP 프로토콜을 통해 Google의 Gemini 모델을 사용하여 텍스트 프롬프트에서 고품질 이미지를 생성합니다.
이 MCP 서버를 통해 모든 AI 비서가 Google의 Gemini AI 모델을 사용하여 이미지를 생성할 수 있습니다. 이 서버는 신속한 엔지니어링, 텍스트-이미지 변환, 파일 이름 생성 및 로컬 이미지 저장을 처리하여 모든 MCP 클라이언트를 통해 AI 생성 이미지를 쉽게 생성하고 관리할 수 있도록 합니다.
Related MCP server: Gemini Image Gen MCP Server
Gemini 2.0 Flash를 사용한 텍스트-이미지 생성
텍스트 프롬프트 기반 이미지-이미지 변환
파일 기반 및 base64 인코딩 이미지 모두 지원
프롬프트 기반 자동 지능형 파일 이름 생성
영어가 아닌 프롬프트의 자동 번역
구성 가능한 출력 경로를 갖춘 로컬 이미지 저장소
생성된 이미지에서 엄격한 텍스트 제외
고해상도 이미지 출력
이미지 데이터와 파일 경로에 직접 액세스
서버는 AI 어시스턴트를 위해 다음과 같은 MCP 도구를 제공합니다.
generate_image_from_text텍스트 프롬프트 설명에서 새로운 이미지를 만듭니다.
지엑스피1
매개변수:
prompt : 생성하려는 이미지에 대한 텍스트 설명
보고:
다음을 포함하는 튜플:
원시 이미지 데이터(바이트)
저장된 이미지 파일(str)의 경로
이러한 이중 반환 형식을 사용하면 AI 보조원이 이미지 데이터를 직접 사용하거나 저장된 파일 경로를 참조할 수 있습니다.
예:
"산 위로 지는 일몰 이미지를 생성합니다"
"공상과학 도시에서 사진처럼 사실적인 비행 돼지를 만들어 보세요"
이 이미지는 다음 프롬프트를 사용하여 생성되었습니다.
"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?"
푸른 나무로 가득한 미래형 SF 도시 위를 날고 있는 날개 달린 3D 렌더링 돼지와 실크햇
Claude Desktop Host와 함께 이 MCP 서버를 사용하는 경우:
성능 문제 : transform_image_from_encoded 사용하면 다른 방법에 비해 처리 시간이 상당히 오래 걸릴 수 있습니다. 이는 MCP 프로토콜을 통해 대용량 base64 인코딩 이미지 데이터를 전송하는 오버헤드 때문입니다.
경로 확인 문제 : Claude Desktop Host를 사용할 때 이미지 경로를 올바르게 확인하는 데 문제가 있을 수 있습니다. 호스트 애플리케이션이 반환된 파일 경로를 제대로 해석하지 못해 생성된 이미지에 액세스하기 어려울 수 있습니다.
최상의 환경을 위해 가능하다면 대체 MCP 클라이언트나 transform_image_from_file 메서드를 사용하는 것을 고려하세요.
transform_image_from_encodedbase64로 인코딩된 이미지 데이터를 사용하여 텍스트 프롬프트를 기반으로 기존 이미지를 변환합니다.
transform_image_from_encoded(encoded_image: str, prompt: str) -> Tuple[bytes, str]매개변수:
encoded_image : 형식 헤더가 있는 Base64로 인코딩된 이미지 데이터(형식은 "data:image/[format];base64,[data]"여야 함)
prompt : 이미지를 어떻게 변환할 것인지에 대한 텍스트 설명
보고:
다음을 포함하는 튜플:
원시 변환된 이미지 데이터(바이트)
저장된 변환된 이미지 파일(str)의 경로
예:
"이 풍경에 눈을 더하세요"
"배경을 해변으로 바꿔요"
transform_image_from_file텍스트 프롬프트를 기반으로 기존 이미지 파일을 변환합니다.
transform_image_from_file(image_file_path: str, prompt: str) -> Tuple[bytes, str]매개변수:
image_file_path : 변환할 이미지 파일의 경로
prompt : 이미지를 어떻게 변환할 것인지에 대한 텍스트 설명
보고:
다음을 포함하는 튜플:
원시 변환된 이미지 데이터(바이트)
저장된 변환된 이미지 파일(str)의 경로
예:
"이 이미지 속 사람 옆에 라마를 추가하세요"
"이 낮의 장면을 밤처럼 보이게 만들어 보세요"
위에서 만든 날아다니는 돼지 이미지를 사용하여 다음과 같은 프롬프트로 변환을 적용했습니다.
"Add a cute baby whale flying alongside the pig"전에:
후에: 
귀여운 아기 고래가 함께 날아다니는 원래의 날아다니는 돼지 이미지
파이썬 3.11+
Google AI API 키(Gemini)
MCP 호스트 애플리케이션(Claude Desktop App, Cursor 또는 기타 MCP 호환 클라이언트)
Google 계정으로 로그인하세요
"API 키 생성"을 클릭하세요
구성에 사용할 새 API 키를 복사하세요.
참고: API 키는 매월 일정량의 무료 사용량을 제공합니다. Google AI Studio에서 사용량을 확인할 수 있습니다.
저장소를 복제합니다.
git clone https://github.com/your-username/gemini-image-generator.git
cd gemini-image-generator가상 환경을 만들고 종속성을 설치합니다.
# 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 .예제 환경 파일을 복사하고 API 키를 추가하세요.
cp .env.example .envGoogle Gemini API 키와 원하는 출력 경로를 포함하도록 .env 파일을 편집합니다.
GEMINI_API_KEY="your-gemini-api-key-here"
OUTPUT_IMAGE_PATH="/path/to/save/images"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"
}
}
}
}설치 및 구성이 완료되면 다음과 같은 프롬프트를 사용하여 Claude에게 이미지를 생성하거나 변환하도록 요청할 수 있습니다.
"산 위로 지는 일몰 이미지를 생성합니다"
"미래지향적인 도시 풍경을 그림으로 표현해보세요"
"선글라스를 쓴 고양이 그림을 그려보세요"
"장면에 눈을 추가하여 이 이미지를 변형합니다."
"이 사진을 편집해서 밤에 찍은 것처럼 보이게 만들어주세요"
"이 사진의 배경에 날아다니는 용을 추가하세요"
생성/변환된 이미지는 구성된 출력 경로에 저장되고 Claude에 표시됩니다. 업데이트된 반환 유형을 통해 AI 비서는 저장된 파일에 접근하지 않고도 이미지 데이터에서 직접 작업할 수 있습니다.
FastMCP 개발 서버를 실행하여 애플리케이션을 테스트할 수 있습니다.
fastmcp dev server.py이 명령은 로컬 개발 서버를 시작하고 http://localhost:5173/ 에서 MCP Inspector를 사용할 수 있도록 합니다. MCP Inspector는 Claude나 다른 MCP 클라이언트를 사용하지 않고도 이미지 생성 도구를 직접 테스트할 수 있는 편리한 웹 인터페이스를 제공합니다. 텍스트 프롬프트를 입력하고 도구를 실행하면 결과를 즉시 확인할 수 있어 개발 및 디버깅에 유용합니다.
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.
