Skip to main content
Glama

Get the price of an audio piece

soclo_audio_quote
Read-onlyIdempotent

FREE: shows the owner the exact price of one audio piece before anything is spent. Models: music (music bed, 3-600 seconds, priced per started minute), sound_effects (0.5-22 seconds, fractional, priced per second), voiceover (speaks your line in its own language) and soundtrack (scores a described mood). Metered models also need duration. EVERY price — flat recipes included — comes from Soclo’s own free audio quote route: read the quote, never assume a price, and pass its exact expectedCredits and pricingVersion on soclo_audio_make so a moved price refuses uncharged. Show the owner the quote and wait for their yes before making a piece.

Input Schema

NameRequiredDescriptionDefault
modelYesmusic (a music bed) and sound_effects are priced by length; voiceover (speaks a line) and soundtrack (scores a described mood) have a flat price.
durationNoFor music and sound_effects, within that model’s range: music 3-600 seconds; sound_effects 0.5-22 seconds. Fractional seconds are fine (music is priced per started minute). Use the value you quoted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / duration / description
      Previous value: -"For eleven-metered makes, within the quoted model’s own range: eleven_music 3-600 seconds; eleven_sfx 0.5-22 seconds. Fractional seconds are fine (MAIN prices music per started minute). Use the value you quoted."New value: +"For music and sound_effects, within that model’s range: music 3-600 seconds; sound_effects 0.5-22 seconds. Fractional seconds are fine (music is priced per started minute). Use the value you quoted."
    • changedInput schema / properties / model / description
      Previous value: -"eleven_music / eleven_sfx are server-quoted and metered; voiceover / soundtrack are flat-credit recipes."New value: +"music (a music bed) and sound_effects are priced by length; voiceover (speaks a line) and soundtrack (scores a described mood) have a flat price."
    • changedInput schema / properties / model / enum
      Previous value: -[
      -  "eleven_music",
      -  "eleven_sfx",
      -  "voiceover",
      -  "soundtrack"
      -]New value: +[
      +  "music",
      +  "sound_effects",
      +  "voiceover",
      +  "soundtrack"
      +]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds materially beyond them: the call is free, pricing is authoritative (never assumed), and a stale price causes an uncharged refusal at make time. That refusal semantics is the key behavioral trait an agent needs and cannot get from any structured field.

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 core action and the free/no-spend guarantee are front-loaded, and each trailing clause adds real instruction rather than filler. It is somewhat dense and run-on (models, durations, quote-to-make chaining, owner approval all in four sentences), which costs it a point on readability.

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, yet the description compensates by naming the fields the quote returns (expectedCredits, pricingVersion) and what to do with them. With only two parameters and one required enum, nothing an agent needs to call this and chain it into soclo_audio_make is missing.

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

Parameters3/5

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

Schema coverage is 100% and the schema already documents the model enum and duration bounds per model, so the description largely restates it. It adds only a mild hint — 'EVERY price comes from Soclo's own free audio quote route' and 'pass its exact expectedCredits and pricingVersion' — which clarifies reuse of the quoted value but does not extend the parameters themselves. Baseline 3 is right.

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 ('shows the owner the exact price of one audio piece') and enumerates the four models it quotes with their pricing bases. It is immediately distinguishable from soclo_audio_make and the other *_quote siblings (soclo_image_quote, soclo_video_variants_quote, etc.) because it names the audio domain and the pricing units.

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

Usage Guidelines5/5

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

Explicitly prescribes the workflow: read the quote, never assume a price, pass its exact expectedCredits and pricingVersion to soclo_audio_make, and wait for the owner's yes before making a piece. It names the downstream alternative tool and the condition (owner approval) that gates it, plus the consequence of skipping the step (a moved price refuses uncharged).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources