Skip to main content
Glama

Quote a Canvas

quote_canvas
Read-onlyIdempotent

The exact credits for a Spotify Canvas, before anything is charged. Returns quote_id, credits and a breakdown. Always quote first and tell the user the credits before creating; credits are reserved at creation and charged only when the video is delivered.

Input Schema

NameRequiredDescriptionDefault
styleNoOptional visual style
sourceNoai-video (default), ai-image, stock-photo or stock-videoai-video
qualityNoAI video model tier: standard or highstandard
secondsNoCanvas length in whole seconds, 5–8 (default 8). Spotify loops it, so no part of the song is chosen
song_idYesThe song id
metadataNoYour own JSON (an order id, for example): kept with the video and returned in its request. Quote and create with the same value
stock_idNoWith a stock source: the stock photo or video (search_stock with seconds) to use instead of the director's pick
directionNoOptional mood, motifs or references; the concept still comes from the cover
resolutionNo1080p (1080×1920) or 720p1080p
variationsNo1–4 different Canvases
callback_urlNoAn https URL to POST the finished video to (signed; see Callbacks). Quote and create with the same value
feature_artistNoWhether the Canvas shows the artist: auto (the director decides), always or never (AI sources; needs artist photos for "always")auto

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / stock_id / description
      Previous value: -"With a stock source: the Pexels photo or video (search_stock with seconds) to use instead of the director's pick"New value: +"With a stock source: the stock photo or video (search_stock with seconds) to use instead of the director's pick"
  2. Changed1 schema field changed
    • changedInput schema / properties / feature_artist / description
      Previous value: -"Whether the Canvas shows the artist (AI sources; needs artist photos for \"always\")"New value: +"Whether the Canvas shows the artist: auto (the director decides), always or never (AI sources; needs artist photos for \"always\")"
  3. Changed1 schema field changed
    • addedInput schema / properties / stock_id
      Added value: +{
      +  "description": "With a stock source: the Pexels photo or video (search_stock with seconds) to use instead of the director's pick",
      +  "pattern": "^\\d{1,20}$",
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotent and non-destructive, so the safety profile is covered. The description adds genuine billing context not in annotations: credits are reserved at creation and only charged when the video is delivered. It stops short of detailing expiry or quote validity windows.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with what the tool returns, then the critical usage rule, then the billing rationale. No filler; every sentence carries weight.

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?

With no output schema, the description usefully names the return fields (quote_id, credits, breakdown). For a 12-parameter read tool it covers purpose, output and the billing lifecycle well, though it could note whether quote_id must be passed to creation.

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 description coverage is 100%, so all 12 parameters (including enums like style, source, quality) are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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 verb (quote) and resource (Spotify Canvas) and clarifies the output (exact credits before charging). The resource name distinguishes it from quote_lyric_video, though the description never explicitly names that sibling.

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?

"Always quote first and tell the user the credits before creating" gives explicit when-to-use guidance and sequencing relative to create_canvas. The pricing lifecycle (reserved at creation, charged on delivery) reinforces why the quote must precede creation.

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