Maginary Mcp

io.github.maginaryaiPublished by GitHub account maginaryaiv0.3.18Updated Nov 2, 2026

AI image + video generation for agents: --flag prompt DSL, async generate/poll, x402 pay-per-use.

VerifiedStreamable HTTPWeb executableBusiness & CommerceMedia & DesignAI & ML

Overview

AI-generated overview

Maginary MCP lets an assistant generate and edit AI images and video across many model families using a Midjourney-style --flag prompt, with catalog lookup…

What you can do
  • Look up and search the prompt-flag catalog, including categories, statuses and single-flag records
  • Generate images or video from a prompt, then fetch a generation by UUID or poll it until done or failed
  • Run follow-up actions on finished images such as upscale, vary, pan, zoom, img2vid and reroll
  • Upload a local image to get a CDN URL for image-to-image or style-reference prompts (local stdio connections only)
  • Create an account by email or wallet signature, check verification and credits, and create, list or revoke API keys
  • List purchasable plans with pricing, open a Stripe checkout session, and check remaining credits and uploads
When to use it
Useful when you want an assistant to produce or edit images and video from natural-language prompts without wiring up each model provider separately, and to manage the credits and keys behind it. The catalog tools also work without an account if you only need to explore the flag syntax.
Requirements
Either the hosted endpoint at mcp.maginary.ai (OAuth login or a Bearer API key) or a local process via uvx/pip, which needs Python 3.10+ and uv. Generation tools need an account: an API key in MAGINARY_API_KEY, an in-chat signup, or wallet-signed authentication. Network access to the Maginary API; catalog tools fall back to a bundled snapshot offline.
Before you install
Generation and follow-up actions spend credits, and extra prompt flags cost more, so unrequested flags are costly. The checkout tool returns a Stripe payment URL that leads to real payment. Signup returns a generated password to display once, and API keys can be created or revoked. Wallet signup and x402 payment involve signing with a wallet private key and settling on-chain; the server states the signature does not move funds. Local uploads send image files to Maginary's CDN.

Installation

In SourceWeft

  1. Open Maginary Mcp in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.maginaryai%2Fmaginary-mcp/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "maginary": {
      "type": "http",
      "url": "https://mcp.maginary.ai/mcp"
    }
  }
}

README

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:

json
{  "mcpServers": {    "maginary": {      "command": "uvx",      "args": ["--upgrade", "maginary-mcp"]    }  }}

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:

json
"env": { "MAGINARY_API_KEY": "sk-mag-…" }

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:

vardefaultmeaning
MAGINARY_API_KEY—Bearer token from app.maginary.ai/dashboard#api-keys. Skips the in-chat signup flow. Catalog tools work without it.
MAGINARY_BASE_URLhttps://app.maginary.ai/apiOverride for staging or self-hosted.
MAGINARY_MCP_LOG_LEVELINFOStandard Python log level; goes to stderr (stdout is reserved for MCP JSON-RPC).

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.

var (hosted only)defaultmeaning
MAGINARY_MCP_HOST / MAGINARY_MCP_PORT0.0.0.0 / 8642Bind address of the HTTP server.
MAGINARY_PUBLIC_HOSTapp.maginary.aiSent to the backend as X-Forwarded-Host (with -Proto/-For) when MAGINARY_BASE_URL is an internal address, so the backend builds public URLs.
MAGINARY_MCP_REQUIRE_AUTHoffOn: every /mcp call needs a Bearer (OAuth token or API key); without one the server answers 401 + WWW-Authenticate pointing at /.well-known/oauth-protected-resource, which is how Claude/ChatGPT start the login. Trade-off: a wallet-only agent has no Bearer to send, so with the gate on it must make its first x402 payment over plain HTTP (POST /api/gens/) and then connect with a key from POST /api/auth/wallet-account/; the 401 body says so.
MAGINARY_OAUTH_ISSUERhttps://app.maginary.ai/oThe authorization server named in the protected-resource metadata (the backend, django-oauth-toolkit).
MAGINARY_MCP_RESOURCE_URLhttps://mcp.maginary.ai/mcpThis server's canonical resource identifier (RFC 8707 audience). Also what /.well-known/mcp/server-card.json advertises.

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:

json
{  "mcpServers": {    "maginary": { "url": "https://mcp.maginary.ai/mcp" }  }}

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:

json
{  "mcpServers": {    "maginary": {      "url": "https://mcp.maginary.ai/mcp",      "headers": { "Authorization": "Bearer sk-mag-…" }    }  }}

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:

HeaderValue
X-Wallet-AddressLowercased 0x EVM address (42 chars)
X-Wallet-SignatureEIP-191 personal_sign hex over the challenge string
X-Wallet-TimestampUnix seconds (integer)

The challenge string is:

Maginary: authenticate <address> at <timestamp>. This does not move funds.

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.

bash
pip install "maginary-mcp[http]"maginary-mcp-http          # serves /mcp on 0.0.0.0:8642 (MAGINARY_MCP_PORT to change)# — or —docker build -t maginary-mcp . && docker run -p 8642:8642 maginary-mcp

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:

bash
maginary-mcp --install-skill   # -> ~/.claude/skills/maginary-image-gen/SKILL.md

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

bash
cd mcppython -m venv venv && source venv/bin/activatepip install -e .maginary-mcp   # runs on stdio; kill with Ctrl+D

license

MIT.

Source: README.md at commit 33c993a

Tools

16

list_parameters

List parameters

List Maginary prompt-DSL parameters. Args: category: Restrict to one category (e.g. ``composition``, ``video``, ``model``, ``outpaint``). Call with no filters once — the response's ``categories`` / ``statuses`` maps are the full taxonomy. status: Restrict to one status (``live``, ``mostly-dead``, ``unimplemented``). include_reserved: When False (default) drop ``unimplemented`` (recognized-but-blocked) parameters from the result. Returns: A dict with ``count``, ``source`` (``live`` vs. ``bundled-snapshot``), ``categories`` / ``statuses`` (the filter taxonomy), and ``parameters`` (the array of matching entries).

Parametersstatuscategoryinclude_reserved

search_parameters

Search parameters

Text-search over parameter names, aliases, descriptions, values, examples. Args: query: Substring match, case-insensitive. category: Optional single-category restriction. include_reserved: Whether to include ``unimplemented`` parameters. Returns: Dict with ``count``, ``source`` (``live`` vs. ``bundled-snapshot``), and ``parameters`` (ordered as they appear in the catalog).

Parametersqueryrequiredcategoryinclude_reserved

get_parameter

Get parameter

Return the full record for a single parameter (canonical name or alias). Args: name: Parameter name with or without leading ``--`` (e.g. ``ar``, ``--ar``, ``aspect``). Case-insensitive. Returns: The parameter dict. Not-found is an ``isError`` result — surface it rather than fabricating a param.

Parametersnamerequired

generate

Generate image or video

Kick off a generation via POST /api/gens/. Args: prompt: The user's words, passed through as-is. Do NOT add flags the user did not ask for — no ``--ar``, no ``--flagship``, no model flags. Every extra flag costs credits; adding them unrequested is wrong. Standard quality is the default and is cheap; ``--flagship`` is ~4× more expensive and must only be used when the user explicitly asks for best quality. If the user asks about quality or aspect ratio: ask them first (standard vs flagship, landscape vs portrait) before generating. Flags go at the END, only when the user asked: ``--1``/``--2``/``--3``/``--4`` = image count (default 4), ``--ar 16:9`` = aspect ratio, ``--flagship`` = best quality. Unknown flag: call ``get_parameter(name)`` first — never guess. Examples — user says "a fox": prompt is ``"a fox"``. User says "a fox, landscape, best quality": prompt is ``"a fox --ar 16:9 --flagship"``. **Image-to-image (img2img):** Place one or more public image URLs in the prompt, followed by editing instructions: ``"https://cdn.example.com/photo.webp reimagine as oil painting --ar 16:9"`` The engine extracts URLs automatically and switches to img2img mode. Multiple URLs trigger multi-input mode (compositing/combining). Use ``upload_image`` first if images aren't already hosted. **Image-to-video:** Place an image URL in the prompt AND add ``--mp4`` plus video flags (``--5sec``, ``--1080p``). Or use ``execute_action`` with ``action_type="img2vid_basic"`` on a completed generation's image. **Style reference (--sref) is NOT img2img:** ``--sref <url>`` copies the visual *style* of a reference image (colors, mood, composition) without using

Parameterspromptrequiredcallback_url

get_generation

Get generation

Fetch a generation by UUID (GET /api/gens/{uuid}/). Args: uuid: The UUID returned by ``generate``. Returns: The full generation record. If terminal, ``image_urls[]`` holds the finished outputs and ``processing_result.slots[]`` the per-slot detail. NOTE: a generation that failed server-side is a SUCCESSFUL tool call returning ``processing_state: "failed"`` — always check the state, never infer success from the absence of a tool error. **Follow-up actions:** A completed generation's ``processing_result.available_actions`` maps slot indices to valid action types. E.g. ``{"0": ["upscale_2x", "vary_strong", ...], "global": ["reroll"]}``. Use ``execute_action`` with the ``uuid``, a chosen ``action_type``, and the ``parent_image_index`` (the slot key as an int) to run an action. Hosted: a key obtained mid-session may be passed as ``_meta["maginary/api_key"]``.

Parametersuuidrequired

wait_for_generation

Wait for generation

Poll ``get_generation`` on a backoff until it reaches done / failed. Args: uuid: The UUID returned by ``generate``. timeout_s: Return after this many seconds even if still running. Default 45 stays under the 60 s per-call limit most MCP clients enforce; a ``timeout`` result just means "call again". Only raise it (e.g. for video) on clients you know allow long tool calls. Returns: The terminal generation record — which includes generations that failed server-side: those are SUCCESSFUL tool calls returning ``processing_state: "failed"`` with empty ``image_urls``, so always check the state. On tool failure, an ``isError`` result whose ``error`` field is ``"timeout"`` (``message`` names the last observed state — the generation keeps running server-side and can be re-fetched with ``get_generation`` later), ``"auth"``, or ``"failed"``. **Follow-up actions:** A ``done`` generation's ``processing_result.available_actions`` maps slot indices to valid action types — e.g. ``{"0": ["upscale_2x", "vary_strong", "pan_left", "zoom_out_1_5x", "img2img_basic", "img2img_inpaint", "img2vid_basic", ...], "global": ["reroll"]}``. Use ``execute_action`` with the ``uuid``, a chosen ``action_type``, and the ``parent_image_index`` (the slot key as an int) to run an action on a specific output image.

Parametersuuidrequiredtimeout_s

upload_image

Upload image

Upload a local image and get a CDN URL for img2img or ``--sref``. Only available on local (stdio) connections. On hosted/remote connections, place an existing image URL directly in the prompt. Place the returned ``url`` in a ``generate`` prompt: ``generate("https://cdn.maginary.ai/…/photo.webp reimagine as oil painting")`` Args: file_path: Path to an image file on disk (JPEG, PNG, WebP, HEIC). filename: Original filename. Inferred from ``file_path`` if omitted. Returns: Dict with ``url`` (the public CDN URL), ``exists`` (deduplicated), ``credits_deducted``, and ``message``.

Parametersfilenamefile_pathrequired

execute_action

Run action on image

Run a follow-up action on a completed generation's image. After ``generate`` → ``wait_for_generation``, the response's ``processing_result.available_actions`` lists what's possible per slot. Call this tool with one of those action types. Args: generation_uuid: UUID of the parent generation (from ``generate``). action_type: One of the values from ``available_actions`` — e.g. ``"upscale_2x"``, ``"upscale_1_5x"``, ``"vary_strong"``, ``"vary_subtle"``, ``"pan_left"``, ``"pan_right"``, ``"pan_up"``, ``"pan_down"``, ``"zoom_out_2x"``, ``"zoom_out_1_5x"``, ``"img2img_basic"``, ``"img2img_inpaint"``, ``"img2vid_basic"``, ``"reroll"``. parent_image_index: The slot index of the image to act on (0, 1, 2, or 3 for a 4-image grid). Required for per-slot actions; omit for ``"reroll"`` (global action). prompt: Required for ``img2img_basic``, where it is the edit instruction (e.g. ``"make the hat red"``; flags such as ``--2`` or ``--flagship`` may follow it), and for ``img2img_inpaint``, where it is the instruction followed by ``--mask <shapes>`` (e.g. ``"make the hat red --mask rect(.2,.1 .8,.4)"``; the instruction may be empty to just redo the area). Optional otherwise: for ``vary_*`` you can steer the variation with a new prompt; for ``img2vid_basic`` you can describe the desired motion. callback_url: Optional webhook URL (same as ``generate``). Returns: The newly created child generation record (same shape as ``generate``'s return — poll it with ``wait_for_generation``). On failure, same ``isError`` contract as ``generate``: ``"auth"``, ``"payment_required"`` (with x402 challenge), or ``"failed"``.

Parameterspromptaction_typerequiredcallback_urlgeneration_uuidrequiredparent_image_index

create_account

Create account

Create a new Maginary account for the given email address. Returns the auto-generated password — display it to the user ONCE so they can save it. A verification email is sent; the user must click the link before the account can generate images. After verification, use ``manage_api_key(action='create')`` with ``email`` + ``password`` to get an API key, then ``configure_api_key`` to activate it. Args: email: The user's email address. Returns: Dict with ``email``, ``password``, and ``message``. On failure, an ``isError`` result — e.g. ``error: "already_exists"`` (email taken: ask the user for their password or a different email), ``"rate_limited"``, or ``"failed"``.

Parametersemailrequired

create_wallet_account

Create wallet account

Create (or access) a Maginary account using a wallet signature. Sign the message ``Maginary: authenticate <address> at <timestamp>. This does not move funds.`` with EIP-191 ``personal_sign`` and pass all three values. On success, an API key is returned immediately — no email verification needed. Use this when you have a wallet but no email. The returned ``api_key`` should be passed as ``Authorization: Bearer <key>`` in the MCP client config, or via ``configure_api_key`` (stdio) / ``_meta["maginary/api_key"]`` (hosted, per-call). If the wallet already has an account, returns the existing account with a fresh API key. Args: address: EVM wallet address (0x..., 42 chars). signature: Hex-encoded EIP-191 personal_sign of the auth message. timestamp: Unix epoch seconds used in the signed message (must be within the last 5 minutes). Returns: Dict with ``address``, ``api_key`` (full key — show once), ``key_prefix``, ``created`` (bool), ``message``. On failure: ``isError`` with ``error`` = ``"validation"``, ``"signature_failed"``, or ``"rate_limited"``.

Parametersaddressrequiredsignaturerequiredtimestamprequired

check_account_status

Check account status

Check account verification status, credit balance, and API key count. Use this after ``create_account`` to poll whether the user has clicked the verification link. Pass ``email`` + ``password`` (from ``create_account``) for Basic auth, or omit both to use the configured API key. Args: email: Account email (for Basic auth). password: Account password (for Basic auth). Returns: Dict with ``verified`` (bool), ``email``, ``api_key_count``, ``credits_remaining``, ``uploads_remaining``.

Parametersemailpassword

manage_api_key

Manage API key

Create, list, or revoke Maginary API keys (up to 10 per account). Auth: pass ``email`` + ``password`` for Basic auth (onboarding), or omit both to use the configured API key (normal operation). Args: action: One of ``create``, ``list``, ``revoke``. name: Key name (required for ``create``). key_prefix: 8-char prefix of the key to revoke (required for ``revoke``). email: Account email (for Basic auth). password: Account password (for Basic auth). Returns: For ``create``: dict with ``raw_key`` (the full key — show once, then use ``configure_api_key`` to activate it), ``key_prefix``, ``name``. For ``list``: dict with ``keys`` array. For ``revoke``: success/error message.

Parametersnameemailactionrequiredpasswordkey_prefix

configure_api_key

Configure API key

Activate an API key. Local (stdio) servers persist it; hosted does not. Call this after ``manage_api_key(action='create')`` returns a ``raw_key``. On a local server the key is saved to ``~/.config/maginary/api_key`` (chmod 600) and survives restarts. On the hosted server (mcp.maginary.ai) nothing can be stored — auth is per-request: the response will say ``persisted: false`` and the key must be sent as an ``Authorization: Bearer <key>`` header on every request (set it in the MCP client's connection config). Args: api_key: The full API key string returned by ``manage_api_key``. Returns: Confirmation dict.

Parametersapi_keyrequired

get_products

Get products

List available Maginary products/plans with pricing. No authentication required. Use this to present purchase options to the user. The ``novice_pack`` ($10, 150 credits) is the recommended starting point. Returns: Dict with ``count`` and ``products`` — each product carries ``id``, ``short_name``, ``title``, ``description``, ``price_cents``, ``credits``, ``uploads``, ``is_subscription``. (The backend sends a bare array; it is wrapped here because FastMCP validates tool output against the dict annotation and rejects a top-level list.)

Takes no parameters.

checkout

Create checkout link

Create a Stripe checkout session for purchasing a product. Returns a ``checkout_url`` — the user must open it in a browser to complete payment. After payment, credits are provisioned automatically via webhook. **Present the URL exactly as returned, including the ``#fragment`` — do not truncate, reformat, or strip any part of it.** If the agent has a USDC wallet, skip this entirely — just call ``generate`` and the x402 protocol handles payment on-chain. Args: product_id: Product ID from ``get_products``. email: Account email (for Basic auth during onboarding). password: Account password (for Basic auth during onboarding). Returns: Dict with ``checkout_url``. On failure, an ``isError`` result — e.g. ``error: "email_not_verified"`` until the user clicks the verification link, or ``"auth"`` / ``"failed"``.

Parametersemailpasswordproduct_idrequired

get_balance

Get balance

Check remaining credits and uploads for the authenticated account. Args: email: Account email (for Basic auth). password: Account password (for Basic auth). Returns: Dict with ``credits_remaining`` and ``uploads_remaining``.

Parametersemailpassword

Version history

1
  1. v0.3.18LatestSep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts