Skip to main content
Glama
Sign In

ViralMint

by net.viralmint
OverviewDiscussionsAdmin

Plan a music video

music_video_director

Free for the first songs each day; then 3¢ a song. Pass confirm_cents: 3 to allow the charge; with 0 it answers price_changed and charges nothing. Plans the video for a read song in plain words ("neon city at night"); nothing is rendered. It waits up to 20 s for the plan; if it is not ready the answer says poll_again: call music_video_turn(turn_id). Captions on a song are always whole lines (never word sync). Idempotency is keyed on (this token, this tool, idempotency_key).

Args: song_id: a song already read with song_analyze. message: what the user wants, 1-4000 chars, any language. history: the history from the last answer (optional, max 40 turns). music_plan: the last music_plan, to revise it. confirm_cents: the most the user agreed to pay, in cents (3 allows the paid-song charge). idempotency_key: unique per turn (recommended).

Returns: {ok, turn_id, status: done|running, reply, music_plan, chips:[label], dropped, history, cents} or {poll_again, next_tool}. Next: music_video_estimate, then music_video_create.

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": {
      "song_id": "<song_id>",
      "message": "<message>",
      "confirm_cents": "<confirm_cents>"
    },
    "name": "music_video_director"
  }
}

Input Schema

NameRequiredDescriptionDefault
historyNoThe conversation so far: pass back the `history` the last answer gave you.
messageYes
song_idYesA song id from song_from_library.
music_planNoThe `music_plan` from music_video_director.
confirm_centsYesThe most the user agreed to pay, in whole cents: pass 3 to allow the 3-cent song charge; with 0 a paid song answers price_changed and charges nothing.
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 say readOnlyHint=false and destructiveHint=false, and the description supplies exactly the missing context: a 3¢ charge after free daily songs, a 20 s wait with a poll_again path, the fact that nothing is rendered, caption granularity (whole lines only), and idempotency keyed on (token, tool, idempotency_key). These are the costly-to-discover behaviors 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 and largely waste-free, with Args/Returns split out for scanning. The front-loading is imperfect: the first clause is about pricing rather than purpose, and the 3¢/confirm_cents rule is stated twice (opening line and again in Args), which costs a little attention at the point of decision.

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

Completeness4/5

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

For a 6-parameter, nested-object, no-output-schema tool this is close to complete: return fields are spelled out inline, polling and next-tool routing are covered, and the billing gate is unambiguous. The residual gap is the song_id provenance mismatch between description and schema, plus no statement of what `dropped` or `chips` mean in the return payload.

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

Parameters4/5

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

Schema coverage is 83%, so the schema carries most parameter meaning and a 3 is the baseline; the description still adds real value (message accepts any language, history is capped at 40 turns and must be the last answer's history, music_plan is passed back to revise). One weak spot: it says song_id is "a song already read with song_analyze" while the schema says the id comes from song_from_library, which could send an agent down a wrong path.

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

Purpose5/5

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

States a specific verb and resource ("Plans the video for a read song") and immediately bounds the scope with "nothing is rendered," which separates it from the generation siblings. It also names the downstream chain ("Next: music_video_estimate, then music_video_create"), so an agent can place it in the pipeline without opening another schema.

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?

Sequencing guidance is explicit: call music_video_turn(turn_id) when the answer says poll_again, then music_video_estimate and music_video_create. Pricing gate guidance is also clear (confirm_cents 3 allows the charge, 0 yields price_changed). It lacks an explicit "don't use this for X" exclusion, which keeps it from a 5.

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