Skip to main content
Glama
Sign In

ViralMint

by net.viralmint
OverviewDiscussionsAdmin

Generate a music track

studio_music

Costs the price of one AI music track for the project (a track already bought for this genre and length re-selects 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. genre: 1-40 chars, e.g. "lofi". 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 project.music_generating is false.

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

Input Schema

NameRequiredDescriptionDefault
genreYes
project_idYesA project id from studio_list_projects.
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?

With annotations only declaring readOnlyHint=false and destructiveHint=false, the description carries the real behavioral burden and does it well: it discloses the max-charge negotiation model, that refusal (price_changed) charges nothing, that free steps execute immediately, and that idempotency is keyed on (token, tool, idempotency_key) rather than arguments — a subtle retry rule an agent could not infer elsewhere.

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?

The price model is front-loaded, then Args, then Returns, which is a sound order for a paid mutation. Some prose is dense and slightly redundant (the charge/refuse rule is restated in the free-step and confirm_cents sentences), and the mention of 'a standard voice, a visual already bought' references other tools' resources without need.

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, so the Returns block does the work: it names the shape {ok, job_id, reused?, cents, poll} and tells the agent to poll studio_get_project until project.music_generating is false. Combined with the pricing and idempotency rules, an agent has everything needed to call and follow up correctly.

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 75%, and the description adds real meaning on top: confirm_cents is framed as a price ceiling with a documented probing behavior at 0, and idempotency_key is explained in terms of its actual keying semantics rather than just 'any unique string'. Even genre and project_id get a role in the args list, so nothing material is left ambiguous.

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 opening clause states a specific economic action and resource: it charges for one AI music track for a project, and re-selects a previously bought track for free. The generation intent is clear from the title and the 'free step just runs' sentence, but the description never distinguishes this from the sibling `generate_music`, so an agent cannot route between them on this text alone.

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?

It gives a concrete usage protocol: call with confirm_cents: 0 to discover the price of a paid step, expect price_changed with price_cents and no charge, and simply run when the step is free. What is missing is any statement about when to pick this tool over the sibling `generate_music` or a voice/visual step, so alternative selection is left to inference.

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