Z-Image Studio
Z-Image Studio MCP server lets AI agents generate images, inspect available models, and browse generation history.
Generate images from text prompts with optional seed, steps, width, height, and precision; returns metadata, a resource link, and a thumbnail preview.
List available image-generation models and hardware-based recommendations.
List recent image-generation history with pagination via
limitandoffset.Use the tools over stdio, SSE, or Streamable HTTP transports for consistent agent integration.
Generates images locally using Hugging Face models — the Z-Image-Turbo model (Tongyi-MAI/Z-Image-Turbo) and its quantized variants — loaded via the diffusers library, with tools to list available models and precision options plus hardware-based recommendations.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Z-Image Studiogenerate a cinematic digital art piece of a cyberpunk neon city"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Z-Image Studio
A Cli, a webUI, and a MCP server for the Z-Image-Turbo text-to-image generation model (Tongyi-MAI/Z-Image-Turbo and its variants).
This tool is designed to run efficiently on local machines for Windows/Mac/Linux users. It features specific optimizations for NVIDIA (CUDA), AMD on Linux (ROCm), Intel (XPU), and Apple Silicon (MPS), falling back to CPU if no compatible GPU is detected.
![]()
Features
Hybrid Interfaces:
CLI: Fast, direct image generation from the terminal.
Web UI: Modern web interface for interactive generation.
MCP Server: Capability to be called by AI agents.
CLI and core features
Z-Image-Turbo Model: Utilizes the high-quality
Tongyi-MAI/Z-Image-Turbomodel and quatized variants viadiffusers.MPS Acceleration: Optimized for Mac users with Apple Silicon.
ROCm Support: Explicitly supported on Linux for AMD GPUs.
Intel XPU Support: Supports Intel XPU when running an Intel-enabled PyTorch build.
Attention Slicing Auto-detection: Automatically manages memory usage (e.g., enables attention slicing for systems with lower RAM/VRAM) to prevent Out-of-Memory errors and optimize performance.
Seed Control: Reproducible image generation via CLI or Web UI.
Multiple LoRA Support: Upload/manage LoRAs in the web UI, apply up to 4 with per-LoRA strengths in a single generation; CLI supports multiple
--loraentries with optional strengths.Automatic Dimension Adjustment: Ensures image dimensions are compatible (multiples of 16).
Customizable Output Directory: Image output directory can be customized via config file and environment variable.
Web UI features
Multilanguage Support: English, Japanese, Chinese Simplified (zh-CN), and Chinese Traditional (zh-TW) are supported.
History Browser: Efficiently search and browse your past generations with a paginated history that loads more items as you scroll.
Hardware-aware Model Recommendation: The Web UI dynamically presents model precision options based on your system's detected RAM/VRAM, recommending the optimal choice for your hardware. You can also inspect available models and recommendations via the CLI.
Image Sharing: The generated image can be downloaded to browser download directory, conveniently shared via OS share protocol, and copied into clipboard.
Theme Switch: Light, dark and auto themes.
Mobile compatible: Responsive layout for mobile devices.
MCP features
MCP Server (stdio + SSE + Streamable HTTP): Expose tools for image generation, listing models, and viewing history over Model Context Protocol; stdio entrypoints (
zimg mcp,zimg-mcp) for local agents, SSE available at/mcp-sse, and MCP 2025-03-26 Streamable HTTP transport at/mcp.Transport-Agnostic Content: All transports (stdio, SSE, Streamable HTTP) return identical structured content for consistent agent integration.
Client Transport Selection: Clients should try Streamable HTTP (
/mcp) first for optimal performance, falling back to SSE (/mcp-sse) if needed.
Related MCP server: Z-Image Studio MCP Server
Requirements
Python >= 3.11
uv(recommended for dependency management)
Python 3.12+ Note: torch.compile is disabled by default for Python 3.12+ due to known compatibility issues with the Z-Image model architecture. If you want to experiment with torch.compile on Python 3.12+, set ZIMAGE_ENABLE_TORCH_COMPILE=1 via environment variable or in ~/.z-image-studio/config.json (experimental, may cause errors).
GPU acceleration notes
NVIDIA (CUDA): Works with standard PyTorch CUDA builds.
AMD on Linux (ROCm): Explicitly supported on Linux.
Note: AMD GPU support currently requires ROCm, which is only available for Linux PyTorch builds. Windows users with AMD GPUs will currently fall back to CPU.
Installation: Install AMD ROCm drivers/runtime for your distribution. Then install PyTorch with ROCm support (e.g., via
pip install torch --index-url https://download.pytorch.org/whl/rocm6.1or similar). Ensure the PyTorch ROCm version matches your installed driver version.Verification: The app will automatically detect your device as "rocm". You can confirm this by running
zimg models.Troubleshooting:
If the app falls back to CPU, ensure
torch.version.hipis detected.HSA Override: For some consumer GPUs (e.g., RX 6000/7000 series) not officially supported by all ROCm versions, you may need to set
HSA_OVERRIDE_GFX_VERSION(e.g.,10.3.0for RDNA2,11.0.0for RDNA3).Performance:
torch.compileis disabled by default on ROCm due to experimental support. You can force-enable it withZIMAGE_ENABLE_TORCH_COMPILE=1if your setup (Triton/ROCm version) supports it.
Intel (XPU): Supported when PyTorch is built with Intel XPU backend.
Verification: The app will detect your device as "xpu" in
zimg models.Compatibility: CUDA-specific components/features are not guaranteed on XPU.
Apple Silicon (MPS): Uses PyTorch MPS backend on macOS.
Global installation
If you just want the zimg CLI to be available from anywhere, install it as a uv tool:
uv tool install git+https://github.com/iconben/z-image-studio.git
# or, if you have the repo cloned locally:
# git clone https://github.com/iconben/z-image-studio.git
# cd z-image-studio
# uv tool install .After this, the zimg command is available globally:
zimg --helpTo update z-image-studio:
uv tool upgrade z-image-studio
# or, if you have the repo cloned locally, you pull the latest source code:
# git pullWindows Installation
For Windows users, a pre-built installer is available that bundles everything you need:
Download the latest installer from GitHub Releases
Run
Z-Image-Studio-Windows-x64-x.x.x.exeFollow the installation wizard
Launch from the Start Menu:
Z-Image Studio (Web UI): Starts the web server and opens your browser
Z-Image Studio CLI: Opens a console for command-line usage
Installation Details
Install Location:
C:\Program Files\Z-Image StudioUser Data:
%LOCALAPPDATA%\z-image-studio(contains database, LoRAs, and outputs)Uninstall: Use "Add or Remove Programs" or the uninstall shortcut in the Start Menu
System Requirements
Windows 10 or Windows 11
NVIDIA GPU with CUDA support (recommended) or compatible AMD GPU
8GB+ RAM (16GB+ recommended for full precision models)
Docker Installation
Run Z-Image Studio in a container with Docker:
Quick Start
# Create persistent volume
docker volume create zimg-data
# Run the container
docker run -d \
--name z-image-studio \
-p 8000:8000 \
-v zimg-data:/data \
-v zimg-config:/home/appuser/.z-image-studio \
-v zimg-outputs:/data/outputs \
iconben/z-image-studio:latestThen open http://localhost:8000 in your browser.
With Docker Compose
Create a docker-compose.yml file:
services:
z-image-studio:
image: iconben/z-image-studio:latest
container_name: z-image-studio
ports:
- "8000:8000"
volumes:
- zimg-data:/data
- zimg-config:/home/appuser/.z-image-studio
- zimg-outputs:/data/outputs
restart: unless-stopped
volumes:
zimg-data:
zimg-config:
zimg-outputs:Then run:
docker compose up -dWith GPU Support
NVIDIA GPU:
services:
z-image-studio:
image: iconben/z-image-studio:latest
container_name: z-image-studio
ports:
- "8000:8000"
volumes:
- zimg-data:/data
- zimg-config:/home/appuser/.z-image-studio
- zimg-outputs:/data/outputs
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
restart: unless-stopped
volumes:
zimg-data:
zimg-config:
zimg-outputs:AMD GPU (Linux):
services:
z-image-studio:
image: iconben/z-image-studio:latest
container_name: z-image-studio
ports:
- "8000:8000"
volumes:
- zimg-data:/data
- zimg-config:/home/appuser/.z-image-studio
- zimg-outputs:/data/outputs
devices:
- /dev/dri:/dev/dri
restart: unless-stopped
volumes:
zimg-data:
zimg-config:
zimg-outputs:Then run:
docker compose up -dWith Docker Run
Basic:
docker run -d \
--name z-image-studio \
-p 8000:8000 \
-v zimg-data:/data \
-v zimg-config:/home/appuser/.z-image-studio \
-v zimg-outputs:/data/outputs \
iconben/z-image-studio:latestNVIDIA GPU:
docker run -d \
--name z-image-studio \
-p 8000:8000 \
--gpus all \
-v zimg-data:/data \
-v zimg-config:/home/appuser/.z-image-studio \
-v zimg-outputs:/data/outputs \
iconben/z-image-studio:latestAMD GPU (Linux):
docker run -d \
--name z-image-studio \
-p 8000:8000 \
--device /dev/dri:/dev/dri \
-v zimg-data:/data \
-v zimg-config:/home/appuser/.z-image-studio \
-v zimg-outputs:/data/outputs \
iconben/z-image-studio:latestData Persistence
The container uses Docker volumes for persistence:
Volume | Path | Description |
|
| Database and LoRA storage |
|
| Generated images |
|
| User configuration |
Note: The data directories (/data and /data/outputs) are set as defaults in the Dockerfile. Override with environment variables only if needed.
Environment Variables
Variable | Default | Description |
|
| Server bind host |
|
| Server bind port |
| Auto | Base URL for generated links |
|
| Disable MCP endpoints |
| Auto | Force torch.compile |
Development Mode
Mount source code for development:
docker run -d \
--name z-image-studio-dev \
-p 8000:8000 \
-v $(pwd)/src:/app/src \
-v zimg-data:/data \
-e DEBUG=1 \
iconben/z-image-studio:latestManagement Commands
# View logs
docker logs -f z-image-studio
# Stop container
docker stop z-image-studio
# Remove container (data preserved)
docker rm z-image-studio
# Remove all data
docker volume rm zimg-data zimg-outputs zimg-configpip / uv Installation
Install Z-Image Studio via pip or uv:
pip install z-image-studio
# or
uv pip install z-image-studioAfter installation, the zimg command is available globally:
zimg --helpFrom Source
git clone https://github.com/iconben/z-image-studio.git
cd z-image-studio
pip install -e .
# or
uv pip install -e .Usage
After installation, you can use the zimg command directly from your terminal.
1. CLI Generation (Default Mode)
Generate images directly from the command line using the generate (or gen) subcommand.
# Basic generation
zimg generate "A futuristic city with neon lights"
# Using the alias 'gen'
zimg gen "A cute cat"
# Custom output path
zimg gen "A cute cat" --output "my_cat.png"
# High quality settings
zimg gen "Landscape view" --width 1920 --height 1080 --steps 20
# With a specific seed for reproducibility
zimg gen "A majestic dragon" --seed 12345
# Select model precision (full, q8, q4)
zimg gen "A futuristic city" --precision q8
# Skip writing to history DB
zimg gen "Quick scratch" --no-history2. Web Server Mode
Launch the web interface to generate images interactively.
# Start server on default port (http://localhost:8000)
zimg serve
# Start on custom host/port
zimg serve --host 0.0.0.0 --port 9090Once started, open your browser to the displayed URL.
3. MCP Server Mode (Model Context Protocol)
Run Z-Image Studio as an MCP server:
# stdio transport (ideal for local agents/tools); also available as `zimg mcp`
zimg-mcp
# MCP transports are available when you run the web server:
zimg serve # Both Streamable HTTP (/mcp) and SSE (/mcp-sse) available
zimg serve --disable-mcp # Disable all MCP endpointsAvailable tools: generate (prompt to image), list_models, and list_history. Logs are routed to stderr to keep MCP stdio clean.
Connecting an AI agent (e.g., Claude Desktop) to zimg-mcp
Ensure dependencies are installed (
uv sync) and thatzimg-mcpis on PATH (installed viauv tool install .or run locally viauv run zimg-mcp).In Claude Desktop (or any MCP-aware client), add a local mcp server entry like:
{ "mcpServers": { "z-image-studio": { "command": "zimg-mcp", "args": [], "env": {} } } }Adjust the
commandto a full path if not on PATH. If the agent cannot find the zimg-mcp command, you can also try setting the path in environment.Different agents may have slightly different parameters, for example, cline will timeout fast if you do not explicitly set a timeout parameter. Here is the example for cline:
{ "mcpServers": { "z-image-studio": { "command": "zimg-mcp", "type": "stdio", "args": [],, "env": {}, "disabled": false, "autoApprove": [], "timeout": 300 } } }Detailed syntax may vary, please refer to the specific agent's documentation.
For Clients that support remote mcp server, configure the client with the streamable Http mcp endpoint URL (meanwhile keep the server up by running
zimg serve). Here is an example for Gemini CLI:{ "mcpServers": { "z-image-studio": { "httpUrl": "http://localhost:8000/mcp" } } }Detailed syntax may vary, please refer to the specific agent's documentation.
For legacy SSE , run
zimg serveand configure the client with the SSE endpoint URL. Here is an example for Cline CLI:{ "mcpServers": { "z-image-studio": { "url": "http://localhost:8000/mcp-sse/sse" } } }Detailed syntax may vary, please refer to the specific agent's documentation.
The agent will receive tools:
generate,list_models,list_history.
MCP Content Structure
The generate tool returns a consistent content array with three items in this order:
TextContent: Enhanced metadata including generation info, file details, and preview metadata
{ "message": "Image generated successfully", "duration_seconds": 1.23, "width": 1280, "height": 720, "precision": "q8", "model_id": "z-image-turbo-q8", "seed": 12345, "filename": "image_12345.png", "file_path": "/absolute/path/to/image_12345.png", "access_note": "Access full image via ResourceLink.uri or this URL", "preview": true, "preview_size": 400, "preview_mime": "image/png" }SSE/Streamable HTTP Transports:
urlandaccess_notepoint to the absolute image URLStdio Transport:
file_pathandaccess_notepoint to the local file path
ResourceLink: Main image file reference with context-appropriate URI
SSE/Streamable HTTP Transports: Absolute URL built from request context, ZIMAGE_BASE_URL, or relative path
Stdio Transport: file:// URI for local access
URI Building Priority (SSE/Streamable HTTP):
Request Context (via Context parameter) - builds absolute URL from X-Forwarded-* headers
ZIMAGE_BASE_URL environment variable - configured base URL
Relative URL - fallback when no other method available
Example with Context parameter:
@mcp.tool() async def generate_with_context(..., ctx: Context) -> ...: request = ctx.request_context.request proto = request.headers.get('x-forwarded-proto', 'http') host = request.headers.get('x-forwarded-host', 'localhost') return ResourceLink(uri=f"{proto}://{host}/outputs/image.png", ...){ "type": "resource_link", "name": "image_12345.png", "uri": "https://example.com/outputs/image_12345.png", "mimeType": "image/png" }ImageContent: Thumbnail preview (base64 PNG, max 400px)
{ "data": "base64-encoded-png-data", "mimeType": "image/png" }
This structure ensures:
✅ Consistency: Same content for both stdio and SSE transports
✅ Efficiency: No URL/path duplication across content items
✅ Flexibility: ResourceLink provides file access while ImageContent offers immediate preview
✅ Compatibility: Follows MCP best practices for structured content types
Command Line Arguments
Subcommand: generate (alias: gen)
Argument | Short | Type | Default | Description |
|
| Required | The text prompt for image generation. | |
|
|
|
| Custom output filename. Defaults to |
|
|
| Number of inference steps. Higher usually means better quality. | |
|
|
|
| Image width (automatically adjusted to be a multiple of 8). |
|
|
|
| Image height (automatically adjusted to be a multiple of 8). |
|
|
| Random seed for reproducible generation. | |
|
|
| Model precision ( | |
|
|
| LoRA filename or path, optionally with strength ( | |
|
|
| Do not record this generation in the history database. |
Subcommand: serve
Argument | Type | Default | Description |
|
|
| Host to bind the server to. |
|
|
| Port to bind the server to. |
|
|
| Enable auto-reload (for development). |
|
|
| Seconds to wait for graceful shutdown before forcing exit. |
|
|
| Disable all MCP endpoints ( |
Subcommand: models
Argument | Short | Type | Default | Description |
(None) | Lists available image generation models and local cache status (cached flag, cache path, cache size). | |||
| Explicit alias for list behavior ( | |||
|
| Required | Clear local cached files for one precision ( |
Subcommand: info
Argument | Type | Default | Description |
|
|
| Output application diagnostics as JSON (for scripts/tools). |
(none) | Shows version, runtime details, resolved data/config/output paths, env overrides, and hardware probe info. |
Subcommand: mcp
Argument | Type | Default | Description |
(none) | Stdio-only MCP server (for agents). Use |
Data Directory and Configuration
By default, Z-Image Studio uses the following directories:
Data Directory (Database, LoRAs):
~/.local/share/z-image-studio(Linux),~/Library/Application Support/z-image-studio(macOS), or%LOCALAPPDATA%\z-image-studio(Windows).Output Directory (Generated Images):
<Data Directory>/outputsby default.
Configure the directory
Config File:
~/.z-image-studio/config.json(created on first run after migration).Override the data directory with
Z_IMAGE_STUDIO_DATA_DIR.If you want the output directory sit in another location instead of the data directory, you can override it with
Z_IMAGE_STUDIO_OUTPUT_DIR.Set
"disable_history": trueto turn off generation history entirely (useful on shared deployments). No generation records are written and the history panel is hidden in the web interface. Can also be set to1via theZIMAGE_DISABLE_HISTORYenvironment variable.
Directory structure inside Data Directory by default:
zimage.db: SQLite databaseloras/: LoRA modelsoutputs/: Generated image files
One-time Migration (automatic)
On first run without an existing config file, the app migrates legacy data by moving:
outputs/,loras/, andzimage.dbfrom the current working directory (old layout) into the new locations.
Screenshots
(Screenshot 1: Two column layout with History browser collapsed)
(Screenshot 2: Three column layout with History browser pinned)
(Screenshot 3: Generated Image zoomed to fit the screen)
Development
Installation in Project Virtual Environment
Clone the repository:
git clone https://github.com/iconben/z-image-studio.git cd z-image-studio
To run the source code directly without installation:
Run CLI:
uv run src/zimage/cli.py generate "A prompt"Run Server:
uv run src/zimage/cli.py serve --reloadRun tests:
uv run pytest
Optional: Install in editable mode:**
First install it:
```bash
uv pip install -e .
```
After this, the `zimg` command is available **inside this virtual environment**:
Then use the zimg command in either ways:
Using `uv` (recommended):
```bash
uv run zimg generate "A prompt"
```
or use in more traditional way:
```bash
source .venv/bin/activate # Under Windows: .venv\Scripts\activate
zimg serve
```Optional: Override the folder settings with environment variables
If you do not want your development data mess up your production data,
You can define environment variable Z_IMAGE_STUDIO_DATA_DIR to change the data folder for
You can also define environment variable Z_IMAGE_STUDIO_OUTPUT_DIR to change the output folder to another separate folderDocker Development
Build and run with Docker:
# Build the image
docker build -t z-image-studio:dev .
# Run with source mounted for hot-reload
docker run -d \
--name zimg-dev \
-p 8000:8000 \
-v $(pwd)/src:/app/src \
-v zimg-data:/data \
-e DEBUG=1 \
-e ZIMAGE_ENABLE_TORCH_COMPILE=1 \
z-image-studio:devOr use Docker Compose:
docker compose up -dEnvironment Variables
Variable | Description |
| Force enable |
| Override the default data directory location. |
| Override the default output directory location. |
| Disable generation history entirely: nothing is recorded to the database and the history panel is hidden in the web interface. Set to |
Notes
Guidance Scale: The script hardcodes
guidance_scale=0.0as required by the Turbo model distillation process.Safety Checker: Disabled by default to prevent false positives and potential black image outputs during local testing.
For detailed architecture and development guidelines, see docs/architecture.md.
Available Tools
3 toolsgenerateA
Generate an image from a text prompt.
Returns a consistent content array for both stdio and SSE transports:
1. TextContent: Enhanced metadata including generation info and file details
2. ResourceLink: Main image file reference with context-appropriate URI:
- SSE: Absolute URL built from request context (X-Forwarded-* headers), ZIMAGE_BASE_URL, or relative path
- Stdio: file:// URI for local access
3. ImageContent: Thumbnail preview (base64 PNG, max 400px)
URI Building Priority (SSE):
1. Context parameter (ctx.request_context.request) - builds absolute URL from request headers
2. ZIMAGE_BASE_URL environment variable - uses configured base URL
3. Relative URL - fallback when no other method available
File metadata (filename, file_path) is in TextContent to avoid duplication in ResourceLink.
For long-running operations (high steps/large images), this function will:
- Send progress notifications at key milestones via ctx.report_progress()
- Handle client disconnections gracefully
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| steps | No | Number of inference steps (max bounded by server config) | |
| width | No | Image width in pixels (max bounded by server config) | |
| height | No | Image height in pixels (max bounded by server config) | |
| prompt | Yes | ||
| precision | No | q8 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses return structure (three content types), transport-dependent URI building, progress notifications for long-running operations, and client disconnection handling. It is transparent about key behaviors, though it omits side effects or auth requirements.
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 front-loads the core purpose and uses structured bullet points for return type details and URI building priority. While somewhat verbose on transport specifics, it is well-organized and each section adds meaningful detail.
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 6 parameters, no annotations, and existing output schema, the description covers the tool's operation and return structure but lacks constraints on parameter values (e.g., valid ranges for steps/dimensions) and usage examples. It is adequate but not complete.
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 has 50% description coverage for 6 parameters. The description does not elaborate on any parameter meanings or constraints beyond the schema's own descriptions, failing to add value for the agent's understanding of parameters like seed, precision, etc.
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 begins with a clear statement: 'Generate an image from a text prompt.' This provides a specific verb and resource, and the tool is easily distinguishable from its siblings (list_history, list_models).
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 image generation but does not explicitly tell when to use this tool versus alternatives, nor does it provide conditions for not using it. No exclusions or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_historyB
List recent image generations history.
Returns no records when history is disabled (disable_history config or
ZIMAGE_DISABLE_HISTORY env var), even if the database holds older entries.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does disclose a non-obvious trait — the tool returns zero records when history is disabled even though older rows exist in the database — but omits sort order, pagination behavior, and whether the operation is read-only (only implied by 'List').
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?
Two short sentences, purpose front-loaded, and the disabled-history caveat earns its place because it prevents a misinterpretation of empty results. Slightly verbose parenthetical detail about config/env var but still tight.
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?
An output schema exists, so return shapes need not be described, and the empty-result caveat is valuable. However, for a paginated listing tool with two undocumented parameters, the description leaves the agent without guidance on page size or how to retrieve older entries.
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?
Two parameters exist (limit, offset) with 0% schema description coverage, and the description never mentions them. The word 'recent' vaguely hints at ordering but does not explain paging, defaults (10/0), or maximum values, so it fails to compensate for the schema gap.
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?
Specific verb ('List') plus specific resource ('recent image generations history'), which an agent can clearly distinguish from siblings 'generate' and 'list_models'. It stops short of explicitly naming those siblings as alternatives, but the resource boundary is unambiguous.
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?
Usage is only implied ('recent generations history'), with no statement of when to prefer this over list_models or generate, and no prerequisites. The one genuine guideline given is a negative condition: results are empty if history is disabled via config or env var.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsA
List available image generation models and hardware recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosing behavior. It states the tool lists models and hardware recommendations, implying a read-only operation with no side effects. The behavior is clear for a simple list operation.
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 sentence of nine words, front-loaded with the verb 'List'. Every word is necessary, and there is no extraneous 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 tool has no parameters and an output schema exists (to describe return values), the description is largely sufficient. It covers the tool's purpose, though it lacks mention of when it should be called or any prerequisites.
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?
There are no parameters, and schema coverage is trivially 100%. The description adds no parameter information because none exist, meeting the baseline for high coverage.
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 lists available image generation models and hardware recommendations. It uses a specific verb ('List') and resource ('image generation models'), and distinguishes from siblings ('generate' and 'list_history') by its function.
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 does not explicitly state when to use this tool versus alternatives, but the context of sibling tools implies it is used before 'generate' to see available models. No 'when-not' or alternative references are provided.
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.
3 tool updates
v0.1.0- First observed
generate - First observed
list_history - First observed
list_models
TDQS
Scored across 3 tools
Each tool has a clearly distinct target: list_history reads past generations, list_models reads available models/hardware, and generate creates a new image. The two list_* tools differ in resource domain (history vs. models), so misselection is unlikely.
Two tools follow a clean verb_noun pattern (list_history, list_models), while generate is a bare verb without a noun object. This is a minor deviation but still readable and predictable overall.
Three tools is lean but each earns its place: generation, model discovery, and history review cover the essential loop of a focused image studio. It sits at the low end, but nothing feels redundant or missing from the core scope.
The core workflow (discover models → generate → review history) is covered, and images are returned via ResourceLink/ImageContent. However, there is no way to fetch a specific history entry, delete or prune history, or check status of a long-running generation, leaving notable gaps.
Maintenance
Related MCP Connectors
MCP server for Qwen Image 3 AI image generation
MCP server for building and testing AI agents with multi-model experimentation and insights.
Chat, image, video, and audio models from many vendors behind one remote MCP server and one key.
Stivio MCP server - AI image-to-video generator via MCP.
Related MCP Servers
- FlicenseNot gradedqualityAmaintenanceEnables AI agents to generate images with the Z-Image-Turbo text-to-image model, list available models, and browse past generation history. It exposes the same structured tools over stdio, SSE, and Streamable HTTP transports for consistent agent integration.-
- FlicenseNot gradedqualityAmaintenanceExposes tools for text-to-image generation, listing available models, and browsing generation history over the Model Context Protocol, so AI agents can create images with the Z-Image-Turbo model locally. It runs over stdio for local agents as well as SSE and Streamable HTTP endpoints for remote clients, returning identical structured content across all transports.-
- FlicenseNot gradedqualityAmaintenanceEnables AI agents to generate images from text prompts via Z-Image-Turbo, list available models, and view generation history over stdio, SSE, or Streamable HTTP transports.-
- FlicenseNot gradedqualityAmaintenanceEnables AI agents and MCP clients to generate images with the Z-Image-Turbo model, list available models, and browse generation history via stdio, SSE, and Streamable HTTP transports.-