AI Router · CLI · MCPCheapest eligible quotes before you create
informational · awareness

How MCP image generation works end to end

Trace client, MCP server, Studio API, provider queue, private storage, and signed output.

Get practical MCP creation notes
FAQ interlock

The supported end-to-end trace

In MCP 2026-07-28, a client request carries the protocol version and relevant client capabilities in its _meta field. The optional server/discover request can return server identity, supported versions, and capabilities, but the client may send another request directly and handle a version error instead.

One documented protocol trace is request metadata, optional server discovery, tools/list, and tools/call. OfflineCreator separately documents list_models, generate, get_generation, wait_generation, and download_output as product tools. The cited MCP tool specification defines listing and invocation, while that product tool set defines the media workflow.

Read the sequence as six boundaries: per-request protocol metadata, authorized tool discovery, one server-defined generation call, a returned identifier for later status operations, disclosed provider processing, and owner-authorized output delivery. Each boundary has a different source of truth. The MCP specification defines the first two; OfflineCreator's published interface and product disclosures define the remaining example.

Request context
Required _meta fieldsProtocol version and relevant client capabilities travel with each request.
Optional server discovery
server/discoverThe client may use it, but it is not a prerequisite for another request.
Product workflow
OfflineCreator tool setThe package documents generation, status, waiting, and output tools as its own interface.
Canonical plate

Evidence boundary

The protocol statements on this page are tied to the official MCP 2026-07-28 architecture and tools specification. The OfflineCreator example is tied to its public package record, protected-resource metadata, provider disclosure, and image-generator page accessed on August 8, 2026. Those sources document a published interface and stated product behavior; they do not establish protocol conformance, compatibility with every client, service availability, latency, output quality, or a completed live generation.

Community evidence is excluded from this explanation, and no community claim appears in the ledger. That editorial exclusion does not show that relevant discussion is absent; the evidence brief records community coverage as insufficient.

Transport switch

1. Per-request metadata replaces an initialization prerequisite

The current architecture describes MCP as stateless. Every client request carries io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities in _meta, and normally carries client identity as well. A server can process the request without relying on connection initialization state.

Server discovery is optional in this revision. A client may call server/discover to fetch identity, capabilities, and supported versions together, or send a different request directly and handle a version error. This page does not treat capability negotiation or an initialization exchange as a required first step.

Required on each request
Protocol version and client capabilitiesThese values belong in _meta rather than implicit connection state.
Normally included
Client identityThe architecture says clients should identify themselves unless configured not to.
Optional
Server discoveryUse it for server metadata, not as a mandatory gate before tools/list.
OAuth sequence

2. Discover the authorized tool contract, then call it

A server that declares the tools capability must answer tools/list with the tools currently available to the requesting client. The set may change over time and may vary with authorization presented on the request, but the specification says it must not vary per connection or as a side effect of other requests on that connection.

Each listed tool has a name and input schema. To invoke one, the client sends tools/call with the selected name and arguments. For OfflineCreator, the public package lists list_models and generate among its tools and says the registry is filtered by models, read, and generate scopes. The live protected-resource metadata advertises those three scopes.

List
tools/listRead the tool set available under the authorization on this request.
Select
Name plus input schemaConstruct arguments from the returned definition.
Call
tools/callSend the selected name and arguments with the required request metadata.
Privacy boundary

3. Follow the product's documented asynchronous tools

OfflineCreator's package describes generate as starting a generation. It also documents get_generation for current status and wait_generation for polling until the generation is done. The package README does not turn those names into protocol-level states; they are tools supplied by this server.

That distinction follows the current MCP guidance for work that spans calls. MCP has no protocol-level session or state-handle type. A server that needs continuity should return an explicit handle from one tool and accept that handle as an ordinary argument on later tool calls. The wire protocol does not assign product meaning to that string.

The implementation question at this stage is continuity. Persist the server-returned identifier outside model memory, attach it to later status or wait calls exactly as the published schema requires, and reconcile an uncertain submission before another paid call. This is the operational step that the shorter definition page deliberately does not attempt to teach.

Start
generateThe package describes this tool as starting a Studio generation.
Read status
get_generationThe package assigns current-status retrieval to this tool.
Wait
wait_generationThe package assigns polling until done to this separate tool.
Related circuit

If tools/list omits generate, inspect the authorization used on that request because the current specification permits the tool set to vary by request authorization. If tools/call rejects the name or arguments, compare them with the listed name and input schema. These checks stay inside the MCP tool contract.

If generate returns but later work remains incomplete, use only the status and waiting operations documented by the server. Do not infer a universal provider queue, storage transition, timeout meaning, or refresh operation from the MCP label. OfflineCreator publishes get_generation, wait_generation, and download_output, while MCP treats cross-call handles as ordinary server-defined values.

Missing tool
Check request authorization and tools/listThe available set may vary with authorization presented on the request.
Rejected call
Check listed name and schematools/call uses the server's declared tool contract.
Long-running work
Use documented server toolsDo not invent protocol states beyond the product interface.