image-studio-mcp
image-studio-mcp
中文:image-studio-mcp 是一个本地 stdio MCP server,带 Codex 插件元数据和配套 skill,用来调用 OpenAI 兼容图片接口,完成生图和改图。
English: image-studio-mcp는 Codex 플러그인 메타데이터와 보조 스킬을 포함하는 로컬 stdio MCP 서버로, OpenAI 호환 이미지 API를 호출하여 이미지 생성 및 편집을 수행합니다.
저장소:
기능
generate_image: 텍스트-이미지 생성edit_image: 이미지 편집, 다중 이미지 편집 및 선택적 마스크 편집image_studio_doctor: 연결 및 구성 확인구성 가능한
OPENAI_BASE_URL구성 가능한
OPENAI_API_KEY구성 가능한
OPENAI_IMAGE_MODEL로컬 파일 출력
Codex 플러그인 메타데이터 및 스킬 포함
요구 사항
Node.js 20+OpenAI 호환 이미지 엔드포인트용 API 키
환경 변수
OPENAI_API_KEY中文:必填,图片接口用到的 key。
English: 필수. 이미지 인터페이스에 사용되는 키입니다.OPENAI_BASE_URL中文:可选,默认是https://api.openai.com/v1。
English: 선택 사항. 기본값은https://api.openai.com/v1입니다.OPENAI_IMAGE_MODEL中文:可选,默认是gpt-image-2。
English: 선택 사항. 기본값은gpt-image-2입니다.OPENAI_IMAGE_TIMEOUT_MS中文:可选,默认240000,代理慢或上游慢时可以调大。
English: 선택 사항. 기본값은240000입니다. 프록시나 업스트림이 느릴 경우 값을 늘리십시오.
로컬 설정
npm install
npm run validatenode ./scripts/openai-image-mcp.mjs유용한 명령어:
npm run doctornpm run smoke:test中文:这个 server 用的是 stdio transport,通常由 MCP 宿主拉起,不是手工常驻运行。
English: 이 서버는 stdio 전송 방식을 사용하며, 일반적으로 수동으로 상주 실행하는 것이 아니라 MCP 호스트에 의해 실행됩니다.
image_studio_doctor 확인 항목
中文:
当前宿主是否已经能调用这个 MCP server
当前 server 进程是否拿到了
OPENAI_API_KEY当前
OPENAI_BASE_URL当前
OPENAI_IMAGE_MODEL/models是否可达网关返回了哪些模型
配置中的模型是否出现在
/models结果里
English:
현재 호스트가 이 MCP 서버를 호출할 수 있는지 여부
현재 서버 프로세스가
OPENAI_API_KEY를 가져왔는지 여부현재
OPENAI_BASE_URL현재
OPENAI_IMAGE_MODEL/models에 도달 가능한지 여부게이트웨이가 반환하는 모델 목록
구성된 모델이
/models결과에 나타나는지 여부
中文:如果你想做一次真实、计费的端到端探测,可以在调用 image_studio_doctor 时传 probe_generation=true。
English: 실제 과금되는 종단 간(end-to-end) 테스트를 수행하려면 image_studio_doctor 호출 시 probe_generation=true를 전달하십시오.
Codex에 설치
이 저장소에는 이미 다음이 포함되어 있습니다:
.codex-plugin/plugin.json.mcp.jsonskills/image-studio-mcp/SKILL.md
다른 Codex 워크스페이스에 설치하려면:
image-studio-mcp폴더를 대상 워크스페이스의plugins/디렉토리로 복사합니다.해당 플러그인 디렉토리 내에서
npm install을 실행합니다.로컬 MCP 구성에서
OPENAI_API_KEY를 설정합니다.선택적으로
OPENAI_BASE_URL및OPENAI_IMAGE_MODEL을 조정합니다.마켓플레이스 항목이
./plugins/image-studio-mcp를 가리키는지 확인합니다.플러그인이 앱 실행 중에 추가된 경우 Codex를 다시 시작합니다.
Codex MCP 설정에 나타나지 않는 이유
中文:Codex 里“设置 -> MCP 服务器”通常看的是全局 ~/.codex/config.toml 里的 [mcp_servers.*],不一定会显示插件目录里的 .mcp.json。
English: Codex의 "설정 -> MCP 서버"는 일반적으로 ~/.codex/config.toml의 전역 [mcp_servers.*] 항목을 참조하며, 플러그인 디렉토리의 .mcp.json을 항상 표시하지는 않습니다.
中文:所以“插件能加载”不等于“它会出现在全局 MCP 列表里”。
English: 따라서 "플러그인 로드 가능"이 "전역 MCP 목록에 나타남"을 의미하지는 않습니다.
모든 MCP 호스트에 설치
표준 MCP stdio 전송을 지원하는 모든 호스트에서 이 프로젝트를 사용할 수 있습니다.
구성 예시:
{
"mcpServers": {
"image-studio-mcp": {
"command": "node",
"args": [
"C:/absolute/path/to/image-studio-mcp/scripts/openai-image-mcp.mjs"
],
"cwd": "C:/absolute/path/to/image-studio-mcp",
"env": {
"OPENAI_API_KEY": "your_api_key_here",
"OPENAI_BASE_URL": "https://dash.classicriver.cn/v1/",
"OPENAI_IMAGE_MODEL": "gpt-image-2"
}
}
}
}복사 가능한 예시:
mcp.config.example.json
최소 사용 예시
공식 OpenAI 호환 예시
{
"prompt": "a glossy orange sports car under studio lights",
"output_dir": "C:/workspace/output",
"filename_prefix": "sports-car",
"count": 1,
"size": "1024x1024",
"output_format": "png"
}호환 프록시 예시
{
"prompt": "a cyberpunk city girl with neon signs and rainy streets",
"output_dir": "C:/workspace/output",
"filename_prefix": "cyberpunk-girl",
"count": 1,
"size": "1024x1024",
"quality": "medium",
"output_format": "png"
}편집 예시
{
"prompt": "keep the subject, change the clothes to silver sci-fi armor",
"input_images": [
"C:/workspace/input/original.png"
],
"output_dir": "C:/workspace/output",
"filename_prefix": "armor-edit",
"output_format": "png"
}Codex에서 사용하는 방법
中文:
可以直接说“给我生成一张图”。
更稳的说法是同时告诉它:
生成什么
输出到哪里
要不要多张
是生图还是改图
如果是第一次装好、第一次调用、或者刚切换代理,先让它跑
image_studio_doctor。如果当前宿主只有 skill 文本、没有真实 MCP 工具入口,模型应该明确告诉你“只检测到 skill,没有检测到可调用工具”,而不是假装自己能直接出图。
English:
"이미지 하나 생성해줘"라고 직접 말할 수 있습니다.
더 확실한 방법은 다음 정보를 함께 제공하는 것입니다:
무엇을 생성할지
어디에 저장할지
여러 장을 생성할지 여부
이미지 생성인지 편집인지
설치 후 첫 호출이거나, 프록시를 전환했거나, 이전에 실패한 설정인 경우 먼저
image_studio_doctor를 실행하십시오.현재 호스트에 스킬 텍스트만 있고 실제 MCP 도구 진입점이 없는 경우, 모델은 이미지를 직접 생성할 수 있는 것처럼 가장하지 말고 "스킬만 감지되었으며 호출 가능한 도구가 감지되지 않음"을 명확히 알려야 합니다.
Codex의 컨텍스트 메모리
中文:
会记住,但主要是当前对话线程里的上下文,不是永久记忆。
新对话、上下文压缩、重启后,之前的图片任务细节可能不在。
最稳的做法是让图片保存到明确路径,并在后续继续引用那个路径。
English:
기억하지만, 영구적인 메모리가 아니라 현재 대화 스레드 내의 컨텍스트 위주입니다.
새 대화, 컨텍스트 압축 또는 재시작 후에는 이전 이미지 작업 세부 정보가 사라질 수 있습니다.
가장 안전한 방법은 이미지를 명확한 경로에 저장하고 이후에 해당 경로를 다시 참조하는 것입니다.
도구
image_studio_doctor
中文:做安装后自检、配置排查、代理排查。
English: 설치 후 자가 진단, 구성 문제 해결 및 프록시 문제 해결을 수행합니다.
중요 입력값:
probe_generationprobe_promptmodels_preview_limit
generate_image
中文:根据提示词生成一张或多张图片。
English: 프롬프트를 기반으로 하나 이상의 이미지를 생성합니다.
중요 입력값:
promptoutput_dirfilename_prefixcountsizequalitybackgroundoutput_format
edit_image
中文:基于一张或多张已有图片进行改图。
English: 하나 이상의 기존 이미지를 프롬프트를 기반으로 편집합니다.
중요 입력값:
promptinput_imagesmask_imageoutput_dirfilename_prefixcountsizequalitybackgroundoutput_format
오류 가이드
401 invalid_api_key中文:认证失败,通常是 key 不对、key 对这个代理不可用、或者上游没有授权。
English: 인증 실패. 일반적으로 키가 잘못되었거나, 이 게이트웨이에서 사용할 수 없거나, 업스트림 권한이 없는 경우입니다.404中文:路径大概率不对,常见原因是OPENAI_BASE_URL没写到/v1。
English: 경로가 잘못되었을 가능성이 높습니다. 일반적인 원인은OPENAI_BASE_URL이/v1으로 끝나지 않은 경우입니다.429中文:代理或上游限流了。
English: 프록시 또는 업스트림 속도 제한이 걸린 경우입니다.524中文:代理等上游太久超时了。
English: 프록시가 업스트림 이미지 작업을 기다리는 동안 시간이 초과되었습니다.No available compatible accounts中文:代理当前没有可用的图像账号资源。
English: 프록시에 현재 사용 가능한 이미지 계정 리소스가 없습니다.HTML instead of JSON 中文:通常说明
OPENAI_BASE_URL指到了网页,不是 API。
English: 일반적으로OPENAI_BASE_URL이 API 엔드포인트가 아닌 웹 페이지를 가리키고 있음을 의미합니다.
보안 참고 사항
中文:不要把真实 key 提交进 Git,也不要到处手填进命令历史。优先通过 MCP 宿主的环境变量或本地私有配置注入。
English: 실제 키를 Git에 커밋하지 말고, 명령 기록에 수동으로 입력하지 마십시오. MCP 호스트의 환경 변수나 로컬 개인 구성을 통해 주입하는 것을 우선하십시오.
유효성 검사
node --check ./scripts/openai-image-mcp.mjsnpm run validatenpm run doctornpm run smoke:test스킬 유효성 검사:
python C:/Users/Administrator/.codex/skills/.system/skill-creator/scripts/quick_validate.py ./skills/image-studio-mcpAvailable Tools
2 toolsedit_imageB
Edit one or more source images with a prompt, optionally using a mask, and save the results to local files.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| input_images | Yes | ||
| output_dir | Yes | ||
| mask_image | No | ||
| filename_prefix | No | ||
| count | No | ||
| size | No | ||
| quality | No | ||
| background | No | ||
| output_format | No | ||
| output_compression | No | ||
| user | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the basic operation (edit with prompt, optionally mask, save locally), it lacks critical details such as whether this is a read-only or destructive operation, what permissions or authentication might be required, rate limits, error handling, or what the output looks like (e.g., file paths, success indicators). For a tool with 12 parameters and no annotations, 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, well-structured sentence that efficiently conveys the core functionality. It's front-loaded with the main action and includes key optional elements without unnecessary elaboration. Every word earns its place, making it highly concise.
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 (12 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the behavioral aspects (e.g., mutation effects, error handling), most parameter meanings, or what the tool returns (since there's no output schema). For a tool with this level of complexity, the description should provide more guidance to help an agent use it correctly.
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 0%, meaning none of the 12 parameters have descriptions in the schema. The description only mentions 'prompt', 'mask', and saving to 'local files', which loosely corresponds to 'prompt', 'mask_image', and 'output_dir' parameters. It doesn't explain the purpose or usage of the other 9 parameters (e.g., 'count', 'size', 'quality', 'user'), leaving them undocumented. With low coverage, the description fails to compensate adequately.
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 ('edit'), the target ('one or more source images'), the mechanism ('with a prompt'), and the outcome ('save the results to local files'). It distinguishes from the sibling 'generate_image' by specifying editing of existing images rather than generation from scratch. However, it doesn't specify the type of editing (e.g., inpainting, style transfer) which could make it more specific.
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 editing existing images with a prompt, which differentiates it from 'generate_image' that presumably creates new images. However, it doesn't provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or constraints beyond the optional mask parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_imageC
Generate one or more images from a prompt with an OpenAI-compatible image endpoint and save them to local files.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| output_dir | Yes | ||
| filename_prefix | No | ||
| count | No | ||
| size | No | ||
| quality | No | ||
| background | No | ||
| moderation | No | ||
| output_format | No | ||
| output_compression | No | ||
| user | No |
TDQS
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 saving to local files but doesn't cover critical aspects like rate limits, authentication needs, error handling, or what happens if files already exist. For an 11-parameter tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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, well-constructed sentence that efficiently conveys the core functionality without unnecessary words. It's appropriately sized and front-loaded with 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?
Given the complexity (11 parameters, no annotations, no output schema), the description is inadequate. It covers the basic purpose but lacks parameter explanations, behavioral context, usage guidelines, and output information. For a sophisticated image generation tool, this leaves too many unanswered questions.
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 for 11 parameters, the description must compensate but fails to do so. It mentions 'prompt' and 'output_dir' implicitly through the action description but doesn't explain any of the other 9 parameters like 'size', 'quality', 'background', etc. This leaves most parameters semantically undocumented.
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 ('generate') and resource ('images'), specifying it uses an OpenAI-compatible endpoint and saves to local files. It distinguishes from the sibling 'edit_image' by focusing on generation rather than editing. However, it doesn't explicitly contrast with the sibling tool, so it's not a perfect 5.
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'. It mentions the general context of generating images from prompts but offers no explicit when/when-not instructions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
edit_image - First observed
generate_image
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: edit_image modifies existing images based on a prompt and optional mask, while generate_image creates new images from scratch using a prompt. There is no overlap or ambiguity between these functions.
Both tools follow a consistent verb_noun pattern (edit_image, generate_image) with the same verb style and underscore separation. The naming is perfectly predictable and uniform.
With only 2 tools, this server feels thin for an 'image studio' domain. While the tools cover basic generation and editing, there are likely missing operations like image analysis, format conversion, or batch processing that would be expected in a comprehensive image toolset.
For an image processing server, there are significant gaps in the surface. Missing are tools for tasks like image resizing, filtering, metadata reading, format conversion, or batch operations. The current tools only cover generation and basic editing, leaving many common image workflows unsupported.
Maintenance
Related MCP Connectors
MCP server for Qwen Image 3 AI image generation
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
Hosted MCP server for AI photo editing: nothing to install, no desktop photo editor needed.
461Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.