Skip to main content
Glama

analyze_audio_file

Read-only

Measure local audio files to report per-channel peak/RMS dBFS, DC offset, crest factor, and full-scale samples. Analyzes the first max_seconds (default 30, max 120) and marks partial results.

Instructions

Measure local WAV (integer/float), AIFF/AIFF-C, FLAC, Ogg Vorbis, MP3, AAC or M4A/MP4 (AAC/ALAC) without Live: per-channel sample peak/RMS dBFS, DC offset, crest factor and full-scale samples. Analyzes the first max_seconds (default 30, maximum 120); marks partial results. Not LUFS or true peak. No upload. Compressed files are measured after decoding; this does not recover lost audio. Files are read locally without modification, normalization or upload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
max_secondsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.8.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses no upload, no file modification, no normalization, partial-result marking for truncated analysis, and the caveat that decoding compressed files does not recover lost audio. This is exemplary behavioral context.

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?

The description is dense but efficient: supported formats and measured metrics come first, followed by limits, caveats, and safety guarantees. Every sentence adds meaningful information with no filler.

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?

With an output schema available, return-value documentation is already covered. Description addresses input requirements, analysis scope, safety behavior, and known limitations. An agent has enough context to decide when and how to call this tool correctly.

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 description coverage is 0%, so the description carries the parameter documentation burden. It explains max_seconds thoroughly: default 30, maximum 120, only the first segment analyzed, and partial results marked. It also clarifies that 'path' refers to a local file path, though it never names the parameter directly.

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?

The description opens with a strong verb, 'Measure', and specifies the exact resource: local audio files in named formats with a precise set of metrics. The phrase 'without Live' helps differentiate it from in-session analysis tools like analyze_mix.

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

Usage Guidelines3/5

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

The description clearly scopes when the tool applies: local files, certain formats, and a max_seconds window. However, it does not explicitly name alternatives or state when NOT to use this tool, such as pointing to analyze_mix for live session analysis.

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

Install Server

Other Tools