ViralMint

Generate one scene visual

studio_visual

Costs the price of one AI image or AI clip for a scene (an identical one this project already bought re-binds free). confirm_cents is the most you agree to pay: the step charges what it costs, never more, and refuses with price_changed (charging nothing) when it costs more. Call it with confirm_cents: 0 to learn the price of a paid step (the answer is price_changed with price_cents; nothing is charged). A free step (a standard voice, a visual already bought) just runs. Idempotency is keyed on (this token, this tool, idempotency_key), not on the arguments.

Args: project_id: project. scene_uid: the scene. kind: ai_image | ai_clip. prompt: what to show, 1-600 chars. model: optional model id from studio_enums / list_models. confirm_cents: the most the user agreed to pay, in cents. idempotency_key: unique per purchase (recommended).

Returns: {ok, job_id|null, reused?, cents, poll}: poll studio_get_project until that scene's visual.state is no longer "generating"; the result lands on the scene.

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": {
      "project_id": "<project_id>",
      "confirm_cents": "<confirm_cents>",
      "scene_uid": "<scene_uid>",
      "kind": "<kind>",
      "prompt": "<prompt>"
    },
    "name": "studio_visual"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes
`model`	No
`prompt`	Yes
`scene_uid`	Yes
`project_id`	Yes	A project id from studio_list_projects.
`confirm_cents`	Yes	The most the user agreed to pay, in whole cents (0 learns the price).
`idempotency_key`	No	Any unique string (1-200 printable chars) so a retry never buys twice.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that it charges money, that confirm_cents is a ceiling, that an over-price attempt fails with price_changed and charges nothing, that zero means a free price probe, and that idempotency is keyed on (token, tool, idempotency_key) rather than arguments. For a spend-incurring operation this is exactly the behavior an agent needs before calling.

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?

Dense but every sentence carries information; the price-probe trick and refusal behavior are front-loaded where an agent will read them. The Args/Returns layout aids scanning, though the opening parenthesis about re-binding free visuals is slightly buried and the prompt length limits simply restate the schema.

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?

With 7 parameters, no output schema, and a paid asynchronous side effect, the description supplies the missing pieces: a Returns block naming ok/job_id/reused/cents/poll and the instruction to poll studio_get_project until visual.state leaves "generating". Nothing essential for a correct call 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 coverage is only 43%, but the description compensates: it explains confirm_cents as a maximum with the 0 price-probe trick, points at studio_enums/list_models for model ids, and explains the scoping of idempotency_key. The keyed-idempotency rule is real meaning not expressible in the schema.

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 action and scope: it produces one AI image or AI clip attached to a scene, including a reuse case for already-purchased identical visuals. The leading sentence is framed around cost rather than the generate action, and it never names or distinguishes itself from the sibling generate_image / generate_video_clip tools, so an agent must infer the boundary.

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

Usage Guidelines3/5

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

Gives concrete invocation guidance for a scenario (call with confirm_cents 0 to learn the price, free steps just run, get model ids from studio_enums/list_models), which is useful context. It stops short of saying when to use this scene-visual tool instead of the general image/video generation siblings, and gives no when-not-to-use conditions.

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?