This server provides a local MCP interface for generating and editing images through Azure Foundry, with diagnostics and operation recovery.
get_capabilities: Nonbillable configuration and capability diagnostics; can optionally check credentials but does not verify inference permission.
generate_image: Generates one billable Azure PNG at 1536x864/high quality from a prompt, using a caller-supplied UUID operation ID; replaying same arguments recovers the same artifact without resubmission.
edit_image: Creates one new billable image from exactly one explicit source artifact ID or approved absolute PNG path, using a new UUID operation ID; the source remains unchanged.
get_operation: Looks up a retained operation UUID and recovers a committed artifact after interruption; never submits or resubmits an image request.
The server is designed for local workflows, including GitHub Copilot integration and editable presentation examples, with privacy/cost/recovery considerations.
Provides image generation and editing tools that integrate with GitHub Copilot, enabling AI-assisted creation and modification of images through an Azure Foundry deployment.
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., "@image-gen-mcp Generate a 1536x864 hero image with negative space for a presentation slide."
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.
A local Model Context Protocol (MCP) server for generating and editing images through your own Azure Foundry deployment, with GitHub Copilot and editable presentation workflows.
Status: source-build preview, not a published npm release. The implemented tools have real Azure evidence, actual Copilot CLI evidence and a rendered presentation example. Verified paths include local macOS / Node 22.22.2 / Copilot CLI 1.0.79 and the CLI-backed VS Code 1.139.0 session with CLI-token generation/editing from an installed tarball. Native Local Copilot Chat has a demonstrated preview-off recovery/edit workflow; inline previews encountered a host image-transport failure. Do not equate the two session backends. See the qualification matrix and boundaries. A separate data-only Azure principal also generated and edited while an authenticated management read was denied. Live expired-session behavior remains unverified; ambiguous diagnostics do not claim a unique cause. npm publication remains an open gate.
The configured model profile is gpt-image-2.5-sunburst. V1 deliberately enables
only the live-verified 1536x864, high-quality PNG combination: one image,
one concurrent submission, no automatic retries, prompt rewrites or model
fallback. No exact ChatGPT backend or output parity is claimed.
Tool | Purpose |
| Nonbillable diagnostics; keeps configured, observed and unverified facts separate |
| One new immutable image, identified by a caller-retained operation UUID |
| One explicit artifact or approved local PNG reference; immutable parent/child lineage |
| Recover a saved result after interruption without submitting again |
For an existing compatible deployment:
git clone https://github.com/juanmicrosoft/image-gen-mcp.git
cd image-gen-mcp
npm ci
npm run buildThen follow existing-deployment setup to select credentials,
set the inference endpoint/deployment/output directory, and create a private
client configuration. Do not use an unpublished npx package or paste a key
into shell history. The server is a stdio protocol process, not an interactive
image-generation command.
Starting from scratch? Use the separate owner-tagged Bicep/Azure CLI setup. The normal MCP never creates resources or retrieves management keys. The authorization record explains the required resource-scoped grant and remaining limits; a token or management access alone is not inference permission.
Ask Copilot to generate a hero with negative space, inspect it, then explicitly edit that artifact using a new operation UUID. Results include the immutable full-resolution path, dimensions, hash, lineage, available usage and an optional bounded image preview. Image requests are billable; diagnostics are not.
Related MCP server: platform-eng-copilot
The PptxGenJS example consumes full-resolution artifacts into three editable slides. Its dependencies stay outside the runtime. Reference continuity is probabilistic; generated art does not replace editable text.
Read configuration, client setup/limits, generation, editing, privacy/cost/recovery and bounded live evaluation. Previews can be disabled. Cancellation does not prove that a request stopped or was free; retain the operation ID and inspect it before explicitly submitting again.
For contributors, npm test is offline and requires no Azure credentials.
See testing, CONTRIBUTING.md and
AGENTS.md for the individual-PR, independent-review and evidence rules.
The candidate changelog and release evidence/gates
separate passed offline/package CI from unresolved live-client and publication acceptance.
The software and documentation are MIT licensed. See SECURITY.md. This license does not replace Azure/OpenAI service terms or guarantee rights in generated images or third-party source assets.
Create one new billable image from exactly one explicit source_artifact_id or approved absolute PNG source_path. Provide a self-contained prompt and new operation UUID. The source remains unchanged; masks, URLs and multiple references are unsupported.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | 1536x864 | |
| prompt | Yes | ||
| quality | No | high | |
| source_path | No | Absolute .png path inside an explicitly configured input root. | |
| operation_id | Yes | ||
| source_artifact_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful context on top: the operation is billable, the source remains unchanged (non-destructive), and several input modes (masks, URLs, multiple references) are unsupported. No contradiction with annotations exists.
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?
Three dense sentences with zero filler. The core action and constraints are front-loaded, and each sentence contributes a distinct piece of information: what it creates, what inputs it requires, and what behaviors are excluded.
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 6-parameter tool with no output schema, the description covers invocation requirements well but does not state what is returned on success, how the billable image is surfaced, or whether the result is an artifact id. The sibling get_operation hints at async operation tracking, but this is never connected. Some return-semantics gap remains.
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 only 17%, so the description must compensate. It clarifies the oneOf disjunction between source_artifact_id and source_path, qualifies source_path as 'approved absolute PNG', and explains operation_id as a fresh UUID and prompt as 'self-contained'. Optional size/quality enums are not described, but they have single allowed values and defaults, so the gap is minor.
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 opening clause 'Create one new billable image from exactly one explicit source_artifact_id or approved absolute PNG source_path' names the verb, resource, and the key input constraint. It clearly implies editing an existing artifact rather than generating from scratch, distinguishing it from the generate_image sibling without confusion.
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 gives strong input conditions ('exactly one', 'approved', 'self-contained') and explicitly lists what is unsupported ('masks, URLs and multiple references'). However, it never explicitly says when to prefer this over generate_image or get_operation; the boundary is implied by the word 'source' rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate one billable Azure PNG at native 1536x864/high. Supply and retain a fresh UUID operation_id; replaying identical arguments recovers the same artifact without another submission. No retries, resizing or prompt rewrites.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | 1536x864 | |
| prompt | Yes | ||
| quality | No | high | |
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include idempotentHint=true, so replay behavior is partly structured, but the description adds valuable detail: the operation_id must be fresh and retained, replaying identical arguments returns the same artifact without another submission, and the tool performs no retries, resizing, or prompt rewrites. The billing note is also an important side effect that annotations do not convey.
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 sentences deliver a high density of useful information with no filler. The core outcome is front-loaded, and each clause adds a distinct constraint or behavioral detail. Nothing in the description is redundant with the structured fields.
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 tool with no output schema, the description covers the essential operational facts: output type, dimensions, quality, billing, idempotency, and explicit non-behaviors. It does not describe the exact response envelope or authentication requirements, but it supplies enough for an agent to invoke the tool and understand the artifact contract.
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%, so the description must compensate for the bare schema. It explicitly covers operation_id semantics (fresh UUID, replay behavior), names the exact accepted size and quality ('native 1536x864/high'), and implies the prompt is used verbatim via 'no prompt rewrites'. This meaningfully supplements the schema, even though prompt constraints like maxLength are not restated.
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 states a specific verb and resource: 'Generate one billable Azure PNG'. It also fixes the native size and quality, making the tool's purpose unambiguous. The action clearly contrasts with sibling tools like edit_image and get_operation, so an agent can identify this as the creation tool.
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 verb 'Generate' and the sizing/quality constraints imply the tool is for creating new images, but the description never explicitly says when to prefer it over siblings or what conditions would call for edit_image or get_operation. It provides clear operational context, such as the need for a UUID, but no direct when-to-use versus when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nonbillable configuration and capability diagnostics. Optional credential acquisition does NOT verify inference permission or deployment identity.
| Name | Required | Description | Default |
|---|---|---|---|
| check_credentials | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which conveys safety. The description adds a critical behavioral caveat: optional credential acquisition does NOT verify inference permission or deployment identity, which is valuable for the agent to know. However, it does not elaborate on other behaviors such as what 'capability diagnostics' includes or any side effects beyond the annotation, so it earns a 3.
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 that is clear and front-loaded with the core purpose. The caveat about credential acquisition is placed second, which is effective. It is concise without unnecessary fluff, earning a 4.
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 relative simplicity (one optional parameter, no output schema), the description covers the essential purpose and a key behavioral caveat. However, it lacks specifics on what 'capability diagnostics' return or how to interpret results, and it does not clarify whether credentials are required for certain operations. This is a moderate gap, so a 3 is justified.
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%, so the description must explain the parameter 'check_credentials'. It mentions 'optional credential acquisition', which relates to the parameter, but it does not explicitly state that setting check_credentials to true will attempt credential acquisition or what the implications are. The parameter's meaning is partially implied but not fully specified, so a 3 is appropriate.
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 states the resource ('configuration and capability diagnostics') and a domain ('nonbillable'), but the verb 'get' is generic, and the purpose is somewhat vague. It does not clearly distinguish from siblings like get_operation, which also retrieves information. The mention of 'Nonbillable' hints at a billing context, but the overall purpose could be 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?
There is no explicit guidance on when to use this tool versus alternatives like get_operation. The description implies it is for diagnostics, but does not state when it should be preferred over other sibling tools, nor does it provide context for when credential checking is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a retained operation UUID and recover a committed artifact after interruption. Never submits or resubmits an image request. Unknown completion may still incur charges.
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds two valuable behavioral details: it never submits or resubmits (consistent with readOnly) and warns that unknown completion may still incur charges. This charge caveat is beyond what annotations provide and is important for cost awareness.
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?
Three short sentences with zero filler. The purpose is front-loaded, the exclusion is stated immediately, and the cost warning is a final compact addition. Every sentence earns its place.
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 single-parameter read-only tool with no output schema, the description covers what it does, when to use it, what it doesn't do, and a financial caveat. Annotations handle the safety profile. Nothing critical is missing for an agent to call this tool 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?
The description does not mention the parameter operation_id at all. However, the schema already provides format: uuid, making the parameter self-explanatory. With a single parameter and clear schema, the description adds no extra meaning but also doesn't need to. Baseline for low schema coverage is 3, and here it's adequate because the parameter is trivial.
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 'Look up' and the resource 'retained operation UUID' and 'committed artifact', and explicitly distinguishes it from submission tools by saying it never submits or resubmits an image request. This makes it easy for an agent to understand this is a retrieval/status tool, distinct from generate_image and edit_image.
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 after interruption for recovering artifacts, which provides clear context. It explicitly states it never submits or resubmits, ruling out using this tool for creation. However, it doesn't name the sibling tools directly or explicitly say 'use this instead of generate_image when you need the result of a prior call', so the guidance is strong but not fully explicit.
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.
v0.1.0edit_imagegenerate_imageget_capabilitiesget_operationScored across 4 tools
Each tool targets a clearly distinct operation: capabilities, generation, editing, and operation lookup. There is no meaningful overlap between generate_image and edit_image because the latter requires a source artifact.
All tool names use a consistent snake_case verb_noun pattern: get_capabilities, generate_image, edit_image, get_operation. The naming is predictable and easy to navigate.
Four tools is well-scoped for an image generation server. Each tool covers a necessary part of the workflow without unnecessary redundancy.
The core lifecycle is covered: generate, edit, and recover results via get_operation, plus capabilities discovery. Minor gaps like listing or deleting past operations exist, but they are not essential for the stated purpose.
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
Generate AI images, video, speech, music and presentations from Claude, ChatGPT and Cursor.
Multi-model AI image and video generator. 14 models behind one OAuth-secured MCP endpoint.
Image and video AI tools and your own pipelines, run from any AI assistant.
