Skip to main content
Glama

generate_waveform

Create a PNG waveform image from an audio or video file, with configurable color, scale, size, and optional base64 output for vision models.

Instructions

Generate a PNG waveform image from an audio or video file. Returns the file path and inlined base64 image data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorNoWaveform color in hex or name (such as '0x6366f1', 'white', or 'black'). Default: '0x6366f1'.0x6366f1
scaleNoAmplitude scale: 'lin', 'log', or 'sqrt'. Default: 'lin'.lin
widthNoImage width in pixels. Default: 1200.
heightNoImage height in pixels. Default: 280.
inputPathYesPath to the audio or video file.
outputPathYesDestination path for the PNG image.
includeBase64NoReturn base64 image data in the response for vision models. Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / includeBase64 / default
      Added value: +true
  2. Changed7 schema fields changedv0.4.2
    • changedInput schema / properties / color / description
      Previous value: -"Waveform color in hex format (e.g. 0x6366f1, 0x10b981, white, red)"New value: +"Waveform color in hex or name (such as '0x6366f1', 'white', or 'black'). Default: '0x6366f1'."
    • changedInput schema / properties / height / description
      Previous value: -"Waveform image height in pixels"New value: +"Image height in pixels. Default: 280."
    • changedInput schema / properties / includeBase64 / description
      Previous value: -"Whether to include base64 image data in response for AI vision (default: true)"New value: +"Return base64 image data in the response for vision models. Default: true."
    • changedInput schema / properties / inputPath / description
      Previous value: -"Path to audio or video file"New value: +"Path to the audio or video file."
    • changedInput schema / properties / outputPath / description
      Previous value: -"Target output image path (typically .png)"New value: +"Destination path for the PNG image."
    • changedInput schema / properties / scale / description
      Previous value: -"Waveform amplitude scale"New value: +"Amplitude scale: 'lin', 'log', or 'sqrt'. Default: 'lin'."
    • changedInput schema / properties / width / description
      Previous value: -"Waveform image width in pixels"New value: +"Image width in pixels. Default: 1200."
  3. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / includeBase64
      Added value: +{
      +  "description": "Whether to include base64 image data in response for AI vision (default: true)",
      +  "type": "boolean"
      +}
  4. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description bears the full burden. It does usefully disclose the return payload ('file path and inlined base64 image data'), but it omits side-effect behavior: that a file is written to outputPath, whether an existing file is overwritten, whether parent directories are created, and whether the operation is expensive for long media. That leaves real gaps for a file-writing tool with zero annotation coverage.

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?

Two sentences, zero filler, with the core action front-loaded and the return contract in the second line. Each sentence earns its place, and the return statement is especially valuable given there is no output schema.

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 7-parameter tool with full schema coverage and no output schema, the description covers purpose and return shape adequately. It is not fully complete: supported input formats, overwrite/transactional behavior, and failure modes are unaddressed.

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 every parameter including color, scale, width, height, includeBase64, and the two paths is already documented in the schema. The description adds no syntax or behavioral detail beyond echoing that base64 data may be returned, so the baseline 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?

The description states a specific verb and resource — 'Generate a PNG waveform image from an audio or video file' — which no sibling tool does, so an agent can distinguish it from extract_thumbnail, extract_keyframes, or extract_audio without opening the schema. It stops short of an explicit sibling comparison, keeping it at 4 rather than 5.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus alternatives such as extract_thumbnail or extract_keyframes, nor any stated prerequisites (e.g., that the input must exist locally or which codecs are supported). The use case is inferable from the purpose sentence but nothing in the text actively routes the agent.

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