maginary-mcp
[PyPI] [Python] [License: MIT] [smithery badge]
Model Context Protocol server for Maginary — an abstracted OpenRouter for images and video: ~20 model families (GPT-image-2, Seedance 2, Sora 2, Nano Banana Pro, Flux…) behind one Midjourney-style --flag prompt. 16 tools: full flag catalog, generate / upscale / vary / animate, in-chat signup, billing, and x402 pay-per-use for agents with a wallet.
Watch the demo →
why
Maginary uses a Midjourney-style --flag prompt DSL over an async HTTP API. This server:
- surfaces the full parameter catalog to your LLM so it can pick the right flags
- offers a one-shot
generate tool that hits POST /api/gens/
- offers
get_generation + wait_for_generation for polling to a terminal state
- works offline for the catalog tools (ships a bundled snapshot; refreshed from the live docs endpoint at startup when reachable)
connect
This is an MCP server — you don't run it directly; your AI client (Claude Desktop, Cursor, etc.) launches and talks to it behind the scenes. Just add one config block and start chatting.
Claude Desktop
In Claude Desktop: settings → developer → edit config. That opens claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\). Add:
Restart Claude Desktop. Ask it to generate an image — it will see Maginary's tools automatically.
No account yet? No problem — Claude will walk you through signup (just give it your email). Already have an API key? Add it to skip that step:
Requires Python 3.10+ and uv. Alternatively: pip install maginary-mcp.
configuration
Nothing is required. For the stdio server you'll at most set one variable:
The rest only apply when you run the hosted server yourself (maginary-mcp-http, see below). Directory pages that scan the code list them too; ignore them for local use.
hosted (no-install) — Streamable HTTP
Connect a client straight to the hosted server at https://mcp.maginary.ai/mcp.
Zero install — the server is multi-tenant, so each request is scoped to
whatever credential it arrives with. Two ways to authenticate, pick whichever
fits the client:
Connect (OAuth) — for Claude Desktop, claude.ai, and any other client that
speaks MCP's OAuth spec. Add the server with no headers at all:
Click "Connect" in the client. It opens a login page on app.maginary.ai,
you sign in and approve the requested scopes, and the client holds the token
from then on — no key to generate or paste. Requires the server to be running
with MAGINARY_MCP_REQUIRE_AUTH=1; without it, no login is asked for at all.
API key — for any client that doesn't do the OAuth dance (or if you'd
rather not click through a login), generate a key at
app.maginary.ai/dashboard#api-keys
and send it yourself:
Both are equivalent once connected — same tools, same account. Catalog tools
work with no credential either way; generate / get_generation /
wait_for_generation need one. Run the hosted server yourself with:
paying inside the tool call (x402 over MCP)
No key at all? Call generate anyway. Out of credits (or no account), the
result is isError: true with the x402 PaymentRequired at the top level
(accepts, resource, …) plus error: "payment_required". An x402-capable
MCP client — the x402 SDK's x402MCPSession — signs accepts[0] and calls
the same tool again with the payment in _meta["x402/payment"]. The server
forwards it to the backend as PAYMENT-SIGNATURE; the backend verifies,
settles on Base and, for a wallet with no account, creates one. The settled
result carries the on-chain receipt in _meta["x402/payment-response"] and
x402_receipt. No API key is returned — subsequent requests use wallet-signed
auth headers (X-Wallet-Address, X-Wallet-Signature, X-Wallet-Timestamp)
instead.
The server holds no payment logic; everything is decided by the backend's
/api/gens/ contract.
wallet-signed authentication
After the first x402 payment creates the wallet's account, all subsequent
requests are authenticated by signing a short message with the wallet's
private key. Three headers on every request:
The challenge string is:
with <address> lowercased and <timestamp> the same unix seconds sent in
the header. The timestamp must be within 5 minutes of the server's clock
(30 s of future skew tolerated). No API key management needed — the wallet
is the credential.
The hosted server sets no MAGINARY_API_KEY (keys come per-request). It also
serves /health, a human page at GET /, the OAuth protected-resource metadata
and an MCP server card at /.well-known/mcp/server-card.json (live tool list,
auth posture) for directories that scan a bare URL.
Claude Skill
The server ships an Agent Skill that
teaches the --flag DSL, model selection, and the async generate→poll flow:
The skill stands on its own — hosts without MCP get the DSL plus the raw REST
calls (POST /gens/ → poll). With the server connected, Claude instead calls
search_parameters for the authoritative flag list and generate/wait_for_generation
natively. Re-running updates it; local edits are protected unless you pass --force.
Source: src/maginary_mcp/SKILL.md.
tools
catalog (no auth)
list_parameters(category?, status?, include_reserved=false) — enumerate the catalog
search_parameters(query, category?, include_reserved=false) — text search over names / aliases / desc / examples
get_parameter(name) — full record for one flag (canonical name or alias)
list_parameters responses include the categories / statuses taxonomy, and both
list/search responses carry source (live vs bundled-snapshot).
generation (auth required)
generate(prompt, callback_url?) — POST /api/gens/. Supports img2img: place image URLs in the prompt. Multiple URLs = multi-input compositing. Use --sref <url> for style-only transfer (not img2img).
upload_image(file_path, filename?) — reads a local image file and uploads via POST /api/images/upload/. Returns a CDN URL for use in img2img prompts or --sref. Stdio connections only (hosted: use a URL directly or the REST endpoint).
execute_action(generation_uuid, action_type, parent_image_index?, prompt?, callback_url?) — POST /api/gens/{uuid}/actions/. Run a follow-up on a completed generation's image (upscale, vary, pan, zoom, img2vid, reroll).
get_generation(uuid) — GET /api/gens/{uuid}/. Response includes processing_result.available_actions mapping slots to valid action types.
wait_for_generation(uuid, timeout_s=45) — poll to done / failed; a timeout result means still running — call again
worked example
Inside an MCP-capable client, once configured:
"Search the maginary catalog for anything about aspect ratio."
The LLM calls search_parameters("aspect") and gets back the --ar entry with values, examples, and supported models.
"Now generate a cinematic portrait 16:9 with the flagship model."
The LLM calls generate("a cinematic portrait --ar 16:9 --flagship"), gets a uuid, then wait_for_generation(uuid) and reads image_urls[] out of the terminal record.
"Upscale the first image."
The LLM checks processing_result.available_actions["0"], sees "upscale_2x", calls execute_action(uuid, "upscale_2x", 0), gets a new uuid, then wait_for_generation(new_uuid).
"Edit this photo to look like a watercolor." (user provides a local image)
The LLM calls upload_image("/tmp/photo.png") → gets a CDN URL, then generate("https://cdn.maginary.ai/…/photo.webp reimagine as watercolor painting"). (stdio only — on hosted, the user provides a URL instead.)
catalog freshness
- Live fetch on startup from
https://maginary.ai/docs/parameters.json, 5-second timeout.
- Bundled snapshot at
src/maginary_mcp/parameters_snapshot.json used as a fallback whenever live fetch fails (no network, docs site down, etc.).
- The snapshot is refreshed manually by the maintainer via
python scripts/refresh_snapshot.py — deliberately not baked into the wheel build so a new snapshot always corresponds to a reviewed commit.
The source field on list_parameters / search_parameters responses tells you which one is active.
development
license
MIT.