Frapea

Measure loudness

measure_loudness

Read-onlyIdempotent

MEASURE THE MIX — you cannot hear it; this is how you check it. Mixes the timeline's audio offline exactly as an export does (every audio track, nested timelines, fades, volume keyframes, clip audio effects, ducking, mute/solo) and measures it with EBU R128 / ITU-R BS.1770 — the same meter export loudness normalization uses. The mix is measured AS MIXED: an export's loudnessTargetLufs would then shift all of it by one gain. Returns {jobId}; poll get_job_status every few seconds. When done, result is {durationSec, integratedLufs, truePeakDbtp (4× oversampled, BS.1770-4), samplePeakDbfs, loudnessRangeLu, maxShortTermLufs, windows: [{fromSec, toSec, integratedLufs, maxShortTermLufs}] one per windowSec, sections?: [...same per requested section], speech: {source: transcript|none, speechSec, gapSec, mixDuringSpeechLufs, mixInGapsLufs, transcribedClips, untranscribedClips}, tracks: [{trackId, name, carriesSpeech, integratedLufs, samplePeakDbfs, duringSpeechLufs, inGapsLufs}]} (true peak is measured on the whole mix). SPEECH comes from transcript word timings mapped onto the timeline (trims, nests, speed): a GAP is a stretch of at least 0.6 s with no word within 0.25 s of it. inGapsLufs of a music/ambience track is the bed's level where nobody talks; compare it with the speech track's duringSpeechLufs. Without a transcript (speech.source 'none') the speech/gap fields are null — run start_transcription on the dialogue first. Integrated values are gated (−70 LUFS absolute, −10 LU relative), so silence does not drag them down; null means too short (under 0.4 s) or silent. Needs the project open in the editor tab you are paired with (PROJECT_NOT_OPEN otherwise).

Input Schema

Name	Required	Description
`token`	Yes	The session token `connect` returned. Pass it on every call — it says which browser to drive.
`sections`	No	Optional named spans to report on their own — e.g. the intro, each interview answer. Timeline seconds.
`projectId`	Yes	Project id from get_projects.
`windowSec`	No	Length of each entry in `windows` (3–600 s, default 10).
`timelineId`	Yes	Timeline to measure (what an export of it would sound like).

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, and the description adds rich behavior beyond them: asynchronous job returning jobId with polling, the full result shape, gating rules (−70 absolute, −10 relative) and what null means (under 0.4s or silent). It also discloses the prerequisite and error state an agent must anticipate.

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?

Front-loads the core purpose and the async/polling contract before the dense return-shape breakdown; every clause carries information. It is long and somewhat dense, but the length is justified by the returned data structure it documents.

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?

No output schema exists, so the description carries the full return contract and does so comprehensively—duration, integrated LUFS, true peak oversampling, LRA, windows, sections, speech/gap analysis, per-track breakdown, plus null handling and error conditions. An agent has everything needed to call it and interpret results.

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 coverage is 100%, so the baseline is 3; the description adds meaning by tying `windows` cardinality to windowSec and explaining sections as named per-span reports (intro, interview answers). The remaining required params (projectId, timelineId) are already well described in the schema.

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?

Opens with a specific imperative ('MEASURE THE MIX') and immediately explains the mechanism: offline mix of the timeline's audio measured with EBU R128/BS.1770. It clearly delineates what is included (tracks, nests, fades, keyframes, ducking) and distinguishes this measurement from export normalization, so an agent can tell it apart from siblings like get_analysis_status or inspect_timeline.

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?

Establishes the use case ('you cannot hear it; this is how you check it') and gives a concrete prerequisite: run start_transcription first if there's no transcript, plus the PROJECT_NOT_OPEN failure condition and the poll-get_job_status loop. It doesn't enumerate explicit when-not-to-use or a named alternative for pre-export verification, so not quite 5.

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

All Frapea tools Inspect

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

Need Help?