ViralMint

Generate an image

generate_image

Costs the model's per-image price, charged only after confirm_cents matches the quote: makes one image and saves it to your Library.

Args: prompt: 1-4000 chars. aspect: e.g. 9:16 (default), 16:9, 1:1, 4:5, 3:4. model: an image model id from list_models (optional). reference_library_ids: up to 3 image ids from library_list (kind image). confirm_cents: the price the user agreed to (from tool_cost_estimate); 0 with quote_only. idempotency_key: unique per purchase; a retry with the same key never buys twice. Idempotency is keyed on (this token, this tool, idempotency_key), not on the arguments: reusing an idempotency_key with different arguments returns the first result. quote_only: true returns the price and buys nothing.

Returns: {ok, kind:'image', library_id, model, cents} (use library_get for the file)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>",
      "confirm_cents": "<confirm_cents>"
    },
    "name": "generate_image"
  }
}

Input Schema

Name	Required	Description
`model`	No
`aspect`	No
`prompt`	Yes
`quote_only`	No	true: return the price and buy nothing.
`confirm_cents`	Yes	The price in cents the user agreed to, from tool_cost_estimate or a quote_only call. Pass 0 with quote_only.
`idempotency_key`	No	Any unique string per purchase; a retry with the same key never buys twice.
`reference_library_ids`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries real weight and delivers: charging happens only after confirm_cents matches the quote, quote_only buys nothing, and the non-obvious idempotency scoping rule (keyed on token + tool + key, not arguments, so argument changes return the first result) is spelled out. This is exactly the purchase-safety context an agent needs before spending money.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the cost/confirmation contract, then uses compact Args and Returns blocks with no filler. A few entries restate schema constraints (prompt length, confirm_cents minimum), which is minor redundancy rather than noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter paid generation tool with no output schema, it covers pricing, purchase safety, defaults, parameter sourcing, and the return shape including a pointer to library_get for the file. Nothing essential to calling it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 43%, but the Args block documents all seven parameters with meaning beyond the schema: prompt length, aspect examples with the 9:16 default, model sourced from list_models, reference ids from library_list, confirm_cents traced to tool_cost_estimate, and the retry semantics of idempotency_key. The coverage gap is fully compensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('makes one image and saves it to your Library') plus the billing effect, so the agent knows this is a paid creation tool rather than a listing or lookup. It does not explicitly distinguish itself from adjacent creative siblings such as image_director or generate_thumbnail, leaving that separation implicit in the word 'image'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Lays out a clear workflow: get a price from tool_cost_estimate (or quote_only), then pass the agreed amount as confirm_cents, with idempotency_key unique per purchase. It does not state when to prefer this over sibling generation tools, but the price-first path is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ViralMint tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?