Skip to main content
Glama
Sign In

ViralMint

by net.viralmint
OverviewDiscussionsAdmin

Record the voices

studio_voice

Costs the voice price for the scenes that need a take (a standard voice is free; a Gemini or Premium voice is not). 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. confirm_cents: the most the user agreed to pay, in cents. scene_uids: optional, up to 40 scene ids; omit for every scene without a take. idempotency_key: unique per purchase (recommended).

Returns: {ok, job_id|null, cents, poll}: job_id null = nothing needed recording. Runs in the background: poll studio_get_project until project.voice_job_id is null.

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>"
    },
    "name": "studio_voice"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYesA project id from studio_list_projects.
scene_uidsNo
confirm_centsYesThe most the user agreed to pay, in whole cents (0 learns the price).
idempotency_keyNoAny unique string (1-200 printable chars) so a retry never buys twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare the generic write/non-destructive profile, and the description adds substantial unique behaviour: it charges at most confirm_cents, refuses with price_changed and charges nothing when the price is higher, treats a free step as a no-op pass, and scopes idempotency to (token, tool, idempotency_key) rather than the arguments. It also discloses the asynchronous execution model and the polling target, which no annotation covers.

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-loaded with the pricing contract, and the Args/Returns blocks make it scannable, but the opening sentence ('Costs the voice price...') is awkward and the argument semantics are partly restated between the prose and the Args list.

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?

There is no output schema, and the description compensates with an explicit return shape ({ok, job_id|null, cents, poll}) plus the instruction to poll studio_get_project until voice_job_id is null. For a paid, asynchronous tool this covers everything an agent needs to call and follow up.

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 75% and the description fills the gaps: confirm_cents is defined as a price ceiling with the price_changed refusal semantics and the zero-probe idiom, scene_uids gets its omission behaviour and 40-scene cap, and idempotency_key gains the non-obvious detail that keying ignores arguments. This is meaning well beyond the JSON Schema text.

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?

The description states a specific action on a specific resource: it charges for and records voice takes for scenes lacking one, and distinguishes free (standard) from paid (Gemini/Premium) voices. It does not, however, differentiate itself from the sibling generate_voiceover, so an agent must infer which produces the voice work.

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?

Clear usage context is given: call with confirm_cents 0 to learn the price of a paid step, omit scene_uids to cover every scene without a take, and free steps simply run. What is missing is any explicit exclusion or routing versus alternatives such as generate_voiceover or studio_visual.

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

All ViralMint toolsInspect
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