workbuddy-gpt-image
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GPT_IMAGE_SIZE | No | Requested image size (this is the requested value, not the actual measured result). | 1024x1024 |
| GPT_IMAGE_API_KEY | No | Optional data API key for the local proxy (not an admin token or ChatGPT OAuth token). | |
| GPT_IMAGE_QUALITY | No | Image quality; one of low/medium/high/auto. | low |
| OPENCODEX_API_KEY | No | Optional data API key for the local proxy (not an admin token or ChatGPT OAuth token). Alternative to GPT_IMAGE_API_KEY. | |
| GPT_IMAGE_BASE_URL | No | The base URL of the local OpenCodex proxy. The base should not include /responses; HTTPS is allowed at runtime, but the installer only configures loopback proxies. | http://127.0.0.1:10100/v1 |
| GPT_IMAGE_MAX_QUEUE | No | Maximum queue size. | 8 |
| GPT_IMAGE_MAIN_MODEL | No | The top-level model used to call the tool. Can be the full proxy route ID; cannot strip prefixes arbitrarily. | gpt-5.5 |
| GPT_IMAGE_OUTPUT_DIR | No | The directory where generated images are saved. When launched directly defaults to project outputs; the installer defaults to ~/WorkBuddy/gpt-image. | outputs |
| GPT_IMAGE_STATE_FILE | No | Path to the job state file used by the installer. | ~/.workbuddy/plugin-data/workbuddy-gpt-image/jobs.json |
| GPT_IMAGE_CONCURRENCY | No | Concurrency level for image generation. | 1 |
| GPT_IMAGE_IMAGE_MODEL | No | The model request parameter for the image tool (tools[0].model). If unset, defaults to gpt-image-2; an explicit empty string means tools[0].model is not sent and the upstream selects it. | gpt-image-2 |
| GPT_IMAGE_API_KEY_FILE | No | Path to a file from which to read the API key; an explicit empty string disables automatic reading. | ~/.workbuddy/models.json |
| GPT_IMAGE_OUTPUT_ROOTS | No | List of directories allowed for writing output; on Windows use semicolons as separators. When explicitly set, the allowlist is not automatically widened. | |
| GPT_IMAGE_OUTPUT_FORMAT | No | Requested output format; one of png/jpeg/webp. | png |
| GPT_IMAGE_REFERENCE_ROOTS | No | Optional allowlist of directories from which reference images may be read; by default only paths explicitly given by the caller are accepted, and no scanning is performed. | |
| GPT_IMAGE_QUEUE_TIMEOUT_MS | No | Queue wait timeout in milliseconds. | 600000 |
| GPT_IMAGE_TOTAL_TIMEOUT_MS | No | Total execution timeout in milliseconds. | 600000 |
| GPT_IMAGE_CONNECT_TIMEOUT_MS | No | Timeout for waiting on response headers in milliseconds; increase as needed when the upstream does not send headers for a long time. | 30000 |
| GPT_IMAGE_MAX_RESPONSE_BYTES | No | Size limit for the entire SSE/JSON response in bytes. | 33554432 |
| GPT_IMAGE_MAX_REFERENCE_BYTES | No | Maximum size of a single reference image (12 MiB). | 12582912 |
| GPT_IMAGE_MAX_REFERENCE_COUNT | No | Maximum number of reference images (up to 4). | 4 |
| GPT_IMAGE_MAX_PREVIEW_BASE64_CHARS | No | Maximum base64 preview characters; if exceeded, only the path is returned. Set to 0 to disable previews. | 12000000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_gpt_imageA | 通过配置的 OpenCodex Responses image_generation 调用 GPT 原生生图，不使用 WorkBuddy 内置模型。提交后立即返回 job_id，必须 get_image_job 等到 completed 才能宣称生成成功。参考图只接受用户明确指定的本地文件，将上传至代理所配置的上游；可能消耗额度，不自动重试。 |
| get_image_jobA | 按 job_id 查询或有界等待。完成时返回真实图片路径/尺寸及标准 MCP 图片块；失败绝不冒报成功。 |
| cancel_image_jobA | 取消排队或执行中的本地任务，停止本地等待；不保证上游停止执行或退款。不会触发重试。 |
| check_image_backendA | 仅 GET /models，不生成、不消耗生图额度。可达/列出主模型不代表已验证生图权限，真实生图必须另行调用。 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct lifecycle stage: submit (generate_gpt_image), poll/wait (get_image_job), cancel (cancel_image_job), and backend health (check_image_backend). The descriptions explicitly contrast them, e.g. check_image_backend notes it does not generate while generate_gpt_image warns you must poll with get_image_job.
All four names use strict snake_case with a clear verb_noun form (get_image_job, cancel_image_job, generate_gpt_image, check_image_backend). Consistent convention throughout with shared _image_job / _image_backend suffixes reinforcing grouping.
Four tools map cleanly onto the async image-generation lifecycle with no filler. This is a well-scoped, focused surface for a single-domain server.
Submit, poll, cancel, and backend-check cover the core async lifecycle, and the descriptions make the intended flow clear. Minor gap: no list-jobs or result-retrieval/cleanup operation, so an agent tracking multiple jobs has no enumeration tool.