OpenAI의 DALL-E API를 사용하여 이미지를 생성하는 MCP(Model Context Protocol) 서버입니다.
DALL-E 2 또는 DALL-E 3를 사용하여 이미지 생성
기존 이미지 편집(DALL-E 2만 해당)
기존 이미지의 변형을 만듭니다(DALL-E 2만 해당)
OpenAI API 키 검증
Related MCP server: GPT Image MCP Server
지엑스피1
Cline과 함께 이 DALL-E MCP 서버를 사용할 경우, saveDir 매개변수를 현재 작업 디렉터리와 동일하게 설정하여 생성된 이미지를 현재 작업 공간 디렉터리에 저장하는 것이 좋습니다. 이렇게 하면 Cline이 생성된 이미지를 대화에서 제대로 찾아 표시할 수 있습니다.
Cline의 사용 예:
{
"prompt": "A tropical beach at sunset",
"saveDir": "/path/to/current/workspace"
}# Run the server
node build/index.jsVSCode 설정 내의 Cline MCP 설정 파일에 dall-e 서버를 추가합니다(예: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json):
{
"mcpServers": {
"dalle-mcp": {
"command": "node",
"args": ["/path/to/dalle-mcp-server/build/index.js"],
"env": {
"OPENAI_API_KEY": "your-api-key-here",
"SAVE_DIR": "/path/to/save/directory"
},
"disabled": false,
"autoApprove": []
}
}
}다음 사항을 확인하세요.
/path/to/dalle-mcp-server/build/index.js 빌드된 index.js 파일의 실제 경로로 바꾸세요.
your-api-key-here OpenAI API 키로 바꾸세요.
DALL-E를 사용하여 텍스트 프롬프트를 기반으로 이미지를 생성합니다.
{
"prompt": "A futuristic city with flying cars and neon lights",
"model": "dall-e-3",
"size": "1024x1024",
"quality": "standard",
"style": "vivid",
"n": 1,
"saveDir": "/path/to/save/directory",
"fileName": "futuristic-city"
}매개변수:
prompt (필수): 원하는 이미지에 대한 텍스트 설명
model (선택 사항): 사용할 DALL-E 모델("dall-e-2" 또는 "dall-e-3", 기본값: "dall-e-3")
size (선택 사항): 생성된 이미지의 크기(기본값: "1024x1024")
DALL-E 3: "1024x1024", "1792x1024" 또는 "1024x1792"
DALL-E 2: "256x256", "512x512" 또는 "1024x1024"
quality (선택 사항): 생성된 이미지의 품질, DALL-E 3만 해당("standard" 또는 "hd", 기본값: "standard")
style (선택 사항): 생성된 이미지의 스타일, DALL-E 3만 해당("vivid" 또는 "natural", 기본값: "vivid")
n (선택 사항): 생성할 이미지 수(1~10, 기본값: 1)
saveDir (선택 사항): 생성된 이미지를 저장할 디렉토리(기본값: 현재 디렉토리 또는 .env의 SAVE_DIR). Cline 사용자: 이미지가 제대로 표시되도록 현재 작업 공간 디렉토리로 설정하는 것이 좋습니다.
fileName (선택 사항): 확장자가 없는 생성된 이미지의 기본 파일 이름(기본값: "dalle-{timestamp}")
텍스트 프롬프트를 기반으로 DALL-E를 사용하여 기존 이미지를 편집합니다.
⚠️ 알려진 문제(2025년 3월 18일): DALL-E 2 이미지 편집 API에 현재 버그가 있습니다. 이 버그는 적절한 RGBA 형식 이미지와 마스크를 사용하더라도 프롬프트를 무시하고 편집 없이 원본 이미지를 반환하는 경우가 있습니다. 이 문제는 OpenAI 커뮤니티 포럼 에 보고되었습니다. 이 문제가 발생하는 경우, 더 안정적으로 작동하는 것으로 보이는
create_variation도구를 대신 사용해 보세요.
{
"prompt": "Add a red hat",
"imagePath": "/path/to/image.png",
"mask": "/path/to/mask.png",
"model": "dall-e-2",
"size": "1024x1024",
"n": 1,
"saveDir": "/path/to/save/directory",
"fileName": "edited-image"
}매개변수:
prompt (필수): 원하는 편집 내용에 대한 텍스트 설명
imagePath (필수): 편집할 이미지의 경로
mask (선택 사항): 마스크 이미지 경로(흰색 영역은 편집되고 검은색 영역은 보존됨)
model (선택 사항): 사용할 DALL-E 모델(현재는 "dall-e-2"만 편집을 지원, 기본값: "dall-e-2")
size (선택 사항): 생성된 이미지의 크기(기본값: "1024x1024")
n (선택 사항): 생성할 이미지 수(1~10, 기본값: 1)
saveDir (선택 사항): 편집된 이미지를 저장할 디렉토리(기본값: 현재 디렉토리 또는 .env의 SAVE_DIR). Cline 사용자: 이미지가 제대로 표시되도록 현재 작업 공간 디렉토리로 설정하는 것이 좋습니다.
fileName (선택 사항): 확장자가 없는 편집된 이미지의 기본 파일 이름(기본값: "dalle-edit-{timestamp}")
DALL-E를 사용하여 기존 이미지의 변형을 만듭니다.
{
"imagePath": "/path/to/image.png",
"model": "dall-e-2",
"size": "1024x1024",
"n": 4,
"saveDir": "/path/to/save/directory",
"fileName": "image-variation"
}매개변수:
imagePath (필수): 변형을 생성할 이미지 경로
model (선택 사항): 사용할 DALL-E 모델(현재 "dall-e-2"만 변형을 지원함, 기본값: "dall-e-2")
size (선택 사항): 생성된 이미지의 크기(기본값: "1024x1024")
n (선택 사항): 생성할 변형 수(1~10, 기본값: 1)
saveDir (선택 사항): 변형 이미지를 저장할 디렉토리(기본값: 현재 디렉토리 또는 .env의 SAVE_DIR). Cline 사용자: 이미지가 제대로 표시되도록 현재 작업 공간 디렉토리로 설정하는 것이 좋습니다.
fileName (선택 사항): 확장자가 없는 변형 이미지의 기본 파일 이름(기본값: "dalle-variation-{timestamp}")
OpenAI API 키를 검증합니다.
{}매개변수가 필요하지 않습니다.
참고: 다음 .env 구성은 일반적인 작업이 아닌 테스트 실행에만 필요합니다.
이 프로젝트에 대한 테스트를 개발하거나 실행하려면 OpenAI API 키와 함께 루트 디렉토리에 .env 파일을 만드세요.
# Required for TESTS ONLY: OpenAI API Key
OPENAI_API_KEY=your-api-key-here
# Optional: Default save directory for test images
# If not specified, images will be saved to the current directory
# SAVE_DIR=/path/to/save/directoryCline을 정상적으로 작동시키려면 위의 "MCP 설정에 추가" 섹션에 설명된 대로 MCP 설정 JSON에서 API 키를 구성하세요.
OpenAI의 API 키 페이지 에서 API 키를 얻을 수 있습니다.
# Run basic tests
npm test
# Run all tests including edit and variation tests
npm run test:all
# Run tests in watch mode
npm run test:watch
# Run specific test by name
npm run test:name "should validate API key"참고: 테스트에서는 실제 API 호출을 사용하므로 OpenAI 계정에 요금이 부과될 수 있습니다.
이 프로젝트에는 개발 및 테스트를 위한 테스트 이미지를 생성하는 스크립트가 포함되어 있습니다.
# Generate a test image in the assets directory
npm run generate-test-image이렇게 하면 편집 및 변형 기능을 테스트하는 데 사용할 수 있는 간단한 테스트 이미지가 assets 디렉토리에 생성됩니다.
MIT
Create variations of an existing image using DALL-E
| Name | Required | Description | Default |
|---|---|---|---|
| imagePath | Yes | Path to the image to create variations of | |
| model | No | DALL-E model to use (currently only dall-e-2 supports variations) | |
| size | No | Size of the generated image | |
| n | No | Number of variations to generate (1-10) | |
| saveDir | No | Directory to save the variation images | |
| fileName | No | Base filename for the variation images (without extension) |
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. While 'create variations' implies a generative operation, the description doesn't mention important behavioral aspects like whether this is a read-only operation, what permissions are needed, rate limits, cost implications, or what happens to the original image. For a tool with 6 parameters and no annotation coverage, this is a significant gap.
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 a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for the tool's complexity and gets straight to the point with no unnecessary elaboration.
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 generative AI tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., image paths, URLs, error handling), doesn't mention DALL-E API constraints or costs, and provides no guidance on usage context. The 100% schema coverage helps with parameters, but other critical contextual information is missing.
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 description mentions 'variations of an existing image' which provides context for the 'imagePath' parameter, but doesn't add meaningful semantic information beyond what's already in the schema (which has 100% coverage). The schema descriptions comprehensively document each parameter's purpose, constraints, and enums, so the description adds minimal value here.
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 action ('create variations') and resource ('existing image using DALL-E'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'edit_image' or 'generate_image', but the focus on variations of existing images provides some implicit distinction.
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 no guidance on when to use this tool versus alternatives like 'edit_image' or 'generate_image'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with no contextual usage information beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing image using DALL-E based on a text prompt
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text description of the desired edits | |
| imagePath | Yes | Path to the image to edit | |
| mask | No | Path to the mask image (white areas will be edited, black areas preserved) | |
| model | No | DALL-E model to use (currently only dall-e-2 supports editing) | |
| size | No | Size of the generated image | |
| n | No | Number of images to generate (1-10) | |
| saveDir | No | Directory to save the edited images | |
| fileName | No | Base filename for the edited images (without extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool edits images using DALL-E but omits critical details: whether this is a read/write operation (implied mutation from 'edit'), authentication needs, rate limits, file format requirements, or what happens to the original image. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior 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 a single, efficient sentence that front-loads the core action ('Edit an existing image') and includes essential details (technology and input). There is zero waste or redundancy, making it appropriately sized and well-structured for quick comprehension.
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 tool's complexity (8 parameters, mutation operation, no output schema, and no annotations), the description is incomplete. It lacks information on behavioral traits (e.g., file handling, error cases), output format (what is returned?), and usage context. For a DALL-E editing tool with multiple parameters, this minimal description fails to provide sufficient context for effective agent use.
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 100%, so the schema fully documents all 8 parameters. The description adds no parameter-specific information beyond implying 'prompt' is used for editing. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate with additional semantic context for parameters.
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 verb ('Edit') and resource ('an existing image'), specifying the technology ('using DALL-E') and input mechanism ('based on a text prompt'). It distinguishes from sibling 'create_variation' and 'generate_image' by focusing on editing existing images rather than creating new ones or variations, though it doesn't explicitly contrast with these alternatives.
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 no guidance on when to use this tool versus alternatives like 'create_variation' or 'generate_image'. It doesn't mention prerequisites (e.g., needing an existing image file), exclusions, or specific contexts where editing is preferred over generation. Usage is implied through the action 'edit an existing image' but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image using DALL-E based on a text prompt
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Text description of the desired image | |
| model | No | DALL-E model to use (dall-e-2 or dall-e-3) | |
| size | No | Size of the generated image | |
| quality | No | Quality of the generated image (dall-e-3 only) | |
| style | No | Style of the generated image (dall-e-3 only) | |
| n | No | Number of images to generate (1-10) | |
| saveDir | No | Directory to save the generated images | |
| fileName | No | Base filename for the generated images (without extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the basic function but omits critical behavioral details: whether this is a read-only or mutation operation, rate limits, authentication requirements, cost implications, or what happens when images are saved to 'saveDir'. For a complex 8-parameter tool with no annotation coverage, this is insufficient.
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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's complexity and front-loads the essential information.
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 complex image generation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (image URLs? file paths? metadata?), error conditions, or behavioral constraints. The agent would need to guess about the output format and operational characteristics.
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 100%, so the schema fully documents all 8 parameters. The description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation but not providing extra value. The description doesn't explain relationships between parameters (e.g., 'quality' and 'style' only apply to 'dall-e-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 clearly states the action ('generate') and resource ('image using DALL-E based on a text prompt'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_variation' or 'edit_image', which likely also involve image generation/manipulation.
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 no guidance on when to use this tool versus alternatives like 'create_variation' or 'edit_image'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate the OpenAI API key
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but provides no information about what validation entails, what happens during validation, whether it makes external API calls, what the response format might be, or any error conditions. This leaves significant behavioral gaps.
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 a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple validation tool and front-loads the core functionality immediately.
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 validation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what validation means in this context, what constitutes success/failure, what information is returned, or how the validation is performed. The agent lacks crucial context to understand the tool's behavior and output.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps, and it correctly doesn't mention any parameters. Baseline for 0 parameters with full coverage is 4.
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 action ('validate') and the resource ('OpenAI API key'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools (which are image-related operations), though this isn't necessary since they serve completely different domains.
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 no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for validation, or what constitutes appropriate usage scenarios. The agent must infer usage from the tool name alone.
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.
create_variationedit_imagegenerate_imagevalidate_keyScored across 4 tools
Each tool has a clearly distinct purpose: create_variation modifies an existing image, edit_image alters an image with a prompt, generate_image creates from scratch, and validate_key handles API authentication. There is no overlap in functionality, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern (e.g., create_variation, edit_image, generate_image, validate_key) using snake_case throughout. This predictability enhances readability and usability for agents.
With 4 tools, this server is well-scoped for DALL-E image generation and management. Each tool serves a specific, essential function without bloat, making the set efficient and focused on core operations.
The tools cover key DALL-E operations: generation, editing, and variation creation, plus API key validation. A minor gap is the lack of tools for listing or managing generated images, but core workflows are fully supported without dead ends.
MCP server for NanoBanana AI image generation and editing
MCP server for Midjourney AI image generation and editing
MCP server for Qwen Image 3 AI image generation
MCP server for Flux AI image generation