How do I use acoustic-room-mode-radar?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@acoustic-room-mode-radar analyze my 5x4x2.7m room and recommend acoustic panels for podcasting" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

acoustic-room-mode-radar

by tudadada

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

acoustic-room-mode-radar

npm version License: MIT

Acoustic Room Mode Radar (acoustic-room-mode-radar) is a deterministic Model Context Protocol (MCP) server engineered for room acoustics, home studio design, podcast vocal booths, and audio monitoring environments. It provides zero-hallucination mathematical engines for standing wave room modes (Axial, Tangential, Oblique), Bonello and Bolt dimensional criteria compliance, Schroeder crossover cutoff frequency, Sabine & Norris-Eyring RT60 reverberation decay, and optimal speaker/sweet-spot placement.

🎮 Live Interactive Web Simulator: Experience the zero-install 2D blueprint simulator, sweet-spot 38% rule calculator, and real-time room mode spectrum directly in your browser:
👉 https://tudadada.github.io/acoustic-room-mode-radar/

Capabilities & Tools Included

1. `calculate_room_modes`

Calculates discrete acoustic standing wave room modes up to a cutoff frequency for rectangular enclosures.

Rayleigh Wave Model: Computes exact frequencies ($f_{p,q,r} = \frac{c}{2}\sqrt{(p/L)^2 + (q/W)^2 + (r/H)^2}$) for all Axial (0 dB), Tangential (-3 dB), and Oblique (-6 dB) modes.
Resonance Clustering Detection: Identifies severe degeneracies and modal stacking closer than 1.5 Hz apart.
Bass Isolation Holes: Detects wide gaps (> 18 Hz) below 120 Hz causing hollow bass response.
Bonello 1/3-Octave Criterion (1981): Audits monotonic mode count growth per third-octave band to spot acoustic dips and colorations.
Bolt Area Compliance: Checks room dimensional ratios ($W/H$ and $L/H$) against Richard Bolt's envelope of favorable acoustic proportions.

2. `calculate_schroeder_frequency`

Computes the Schroeder cutoff frequency ($f_s \approx 2000 \sqrt{RT_{60}/V}$), establishing the four operational acoustic regimes:

Zone A (Pressurization): $0 \text{ Hz} \to f_{min}$ (Room acts as sealed pressure chamber).
Zone B (Discrete Modes): $f_{min} \to f_s$ (Standing waves and bass resonance dominate).
Zone C (Diffusion Transition): $f_s \to 4f_s$ (Diffusers and broadband absorption take effect).
Zone D (Specular Ray Acoustics): $> 4f_s$ (Ray acoustics, early reflections, mirror trick).

3. `calculate_rt60_reverb_time`

Calculates reverberation decay time (RT60) across 6 standard octave bands (125 Hz to 4000 Hz) using both Sabine and Norris-Eyring formulations.

Substrate Database: Built-in absorption coefficients for drywall, concrete, glass, hardwood, ceramic tile, commercial carpet, heavy pile, acoustic foam (50mm), rigid fiberglass (100mm), and heavy velour curtains.
Target Usage Presets: Compares current decay against professional targets (podcast_voiceover [0.22 - 0.32s], music_mixing_control [0.28 - 0.38s], home_theater [0.35 - 0.48s], audiophile_listening [0.45 - 0.60s]).
Treatment Prescription: Calculates exact square meters of high-density acoustic treatment panels required to achieve the target decay.

4. `calculate_speaker_listening_position`

Calculates optimal listening sweet spot and stereo monitor coordinates.

38% Room Rule (Westhler Model): Pinpoints listening position at 38.2% (or fallback 44%) room length to balance first-mode nulls and second-mode peaks.
Equilateral Triangle Geometry: Coordinates monitor spacing and toe-in aiming angles (30° inward).
Speaker Boundary Interference Response (SBIR): Calculates first quarter-wavelength cancellation notches from rear and side walls, providing actionable placement adjustments.

Related MCP server: audio-calibration-mcp

Quick Start

Running directly via npx

npx -y acoustic-room-mode-radar

Claude Desktop Integration

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "acoustic-room-mode-radar": {
      "command": "npx",
      "args": ["-y", "acoustic-room-mode-radar"]
    }
  }
}

Cursor Integration

In Cursor Settings > Features > MCP Servers:

Type: command
Command: npx -y acoustic-room-mode-radar

Specification Authority & Verification

All calculations strictly adhere to:

ISO 3382-1: Measurement of room acoustic parameters.
Lord Rayleigh Theory of Sound: Rectangular acoustic cavity modal eigenvalues.
Wallace Clement Sabine & Norris-Eyring: Diffuse field reverberation decay equations.
Richard Bolt & Oscar Bonello Criteria: Statistical distribution of normal modes in small rooms.

License

MIT © datutu ceo@dottheworld.com

Available Tools

4 tools

calculate_room_modesA

Calculates discrete acoustic standing wave room modes (Axial, Tangential, Oblique) up to a cutoff frequency for rectangular enclosures. Evaluates Bonello 1/3-octave band criterion and Bolt dimensional ratio compliance to identify bass resonance clustering and null zones.

ParametersJSON Schema

Name	Required	Description
`width_m`	Yes	Room width across the stereo lateral axis in meters.
`height_m`	Yes	Room ceiling height in meters.
`length_m`	Yes	Room length along the primary listening axis in meters.
`temperature_c`	No	Ambient air temperature in Celsius (affects speed of sound). Default is 20°C.
`max_frequency_hz`	No	Maximum frequency to compute modal resonances for (default 300 Hz).

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the analytical behavior well — modal orders, cutoff handling, Bonello 1/3-octave band criterion, and Bolt ratio compliance — but says nothing about the shape of the returned results (e.g. per-mode frequency lists vs. pass/fail flags).

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 dense sentences with zero filler; the core computation is front-loaded and the analytical criteria follow. Every clause carries information.

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?

There is no output schema, so the description should ideally describe returns; it does so only conceptually (resonance clustering and null zones) rather than structurally. For a stateless calculator with fully documented parameters, this is nearly complete.

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 the schema already documents dimensions, temperature, and cutoff frequency. The description adds no parameter-level detail beyond that, making the baseline 3 appropriate.

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 (calculates) and resource (discrete acoustic standing wave room modes, Axial/Tangential/Oblique) with a stated scope (rectangular enclosures, up to a cutoff frequency). This is clearly distinct from siblings like calculate_schroeder_frequency or calculate_rt60_reverb_time.

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 implies its purpose (identify bass resonance clustering and null zones) but never states when to use it versus calculate_schroeder_frequency or calculate_rt60_reverb_time, nor any prerequisites or exclusions. Usage is inferable from the domain, but no routing guidance is given.

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

calculate_rt60_reverb_timeA

Calculates reverberation decay time (RT60) across octave bands using both classical Sabine and Norris-Eyring formulations. Evaluates decay against target usage presets (Podcast/Voiceover, Studio Mixing, Home Theater, Audiophile) and computes exact additional absorption surface area needed.

ParametersJSON Schema

Name	Required	Description	Default
`width_m`	Yes	Room width in meters.
`height_m`	Yes	Room height in meters.
`length_m`	Yes	Room length in meters.
`target_use`	No	Acoustic destination preset determining recommended RT60 decay target.	podcast_voiceover
`wall_material`	No	Primary wall construction substrate.	drywall_painted
`floor_material`	No	Primary flooring material substrate.	hardwood_floor
`ceiling_material`	No	Ceiling construction substrate.	drywall_painted
`absorber_material`	No	Grade of installed acoustic absorbers.	acoustic_fiberglass_100mm
`existing_absorbers_m2`	No	Surface area in square meters of dedicated acoustic absorbers already installed.

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden, and it does reasonably well: it discloses the two formulations used, that results are reported across octave bands, that decay is compared against a preset target, and that the tool goes further by computing required additional absorber area. It does not describe the shape of the result or units, but for a pure side-effect-free calculation this is solid disclosure.

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, front-loaded with the core computation before the evaluation and remediation outputs. Every clause carries information and there is no filler or restatement of the tool name.

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 nine-parameter physics calculation with no output schema and no annotations, the description conveys what is computed and what the two result components are (per-band decay vs. target, and additional absorption needed). It stops short of describing the result structure or units, which is the main remaining gap given the absence of an output schema.

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 the schema already documents all nine parameters including enums and defaults; that sets the baseline at 3. The description adds only marginal meaning, naming the usage presets and the absorption-area concept, but does not explain how material selections map to absorption coefficients or how existing_absorbers_m2 affects the calculation.

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 states a precise verb+resource ('Calculates reverberation decay time (RT60) across octave bands') and adds the specific methodology (Sabine and Norris-Eyring), which cleanly separates it from siblings like calculate_room_modes or calculate_schroeder_frequency. An agent can identify exactly what this tool computes without opening the schema.

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?

Usage is implied rather than stated: the tool is clearly for evaluating a room's decay time against a listening-destination target, and the four presets hint at intended scenarios. However, there is no explicit when-to-use vs. the three sibling acoustic calculators, and no stated prerequisites (e.g., that room dimensions and materials must be known first).

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

calculate_schroeder_frequencyC

Computes the Schroeder cutoff frequency (cross-over frequency between discrete room resonance modes and statistical reverberant sound fields), establishing the four operational acoustic regimes of the enclosure.

ParametersJSON Schema

Name	Required	Description
`width_m`	Yes	Room width in meters.
`height_m`	Yes	Room ceiling height in meters.
`length_m`	Yes	Room length in meters.
`estimated_rt60_s`	No	Estimated mid-frequency reverberation time (RT60) in seconds (default 0.40s).

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It never states that this is a pure, side-effect-free computation, nor does it give the output unit (Hz) or note that the RT60 parameter has a default, leaving key call expectations unstated.

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?

A single front-loaded sentence that names the operation first and then defines the term. Slightly dense with the parenthetical, but nothing is wasted or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description should have covered the return value and assumptions (e.g., output in Hz, dependence on the supplied RT60 estimate). It alludes to 'four operational acoustic regimes' without explaining them or how the result is used, leaving an agent with a partially informed picture.

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% with all four parameters fully described in the schema, including units, bounds, and the RT60 default. The description adds no parameter-level detail beyond the schema, 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 and resource ('Computes the Schroeder cutoff frequency') and adds a parenthetical definition distinguishing it from plain room-mode calculation. It does not explicitly differentiate itself from the sibling calculate_room_modes, but the defined concept is specific enough to be identifiable.

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?

No guidance on when to prefer this over calculate_room_modes or calculate_rt60_reverb_time, despite the definition depending conceptually on both. No prerequisites or exclusions are stated.

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

calculate_speaker_listening_positionB

Calculates optimal listening sweet spot and stereo monitor coordinates using the 38% Room Rule (Westhler Model) and Equilateral Triangle geometry. Computes Speaker Boundary Interference Response (SBIR) cancellation notches for wall proximity.

ParametersJSON Schema

Name	Required	Description	Default
`setup_type`	No	Acoustic listening configuration style.	studio_monitor_nearfield
`room_width_m`	Yes	Total room width between side walls in meters.
`room_length_m`	Yes	Total room length along the listening axis in meters.
`ceiling_height_m`	Yes	Ceiling height in meters.
`speaker_flushed_soffit`	No	Set true if speakers are mounted flush into the front baffle wall (soffit mounting).

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses what is computed (sweet spot, stereo coordinates, SBIR notches) and the underlying methods, but omits assumptions such as rectangular-room geometry, and says nothing about output format or limits.

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?

Two dense, front-loaded sentences with no filler. Slightly jargon-heavy ('Westhler Model', 'SBIR cancellation notches') but every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-required-parameter computation tool with no output schema and no annotations, the description explains the computation but not the return values (coordinates, dimensions, notch frequencies) or the assumptions behind them, leaving the agent to guess at the result shape.

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 five parameters are already documented at the field level. The description adds no parameter-specific meaning (e.g., how setup_type changes the geometry, or how soffit mounting affects SBIR), 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 and resource ('Calculates optimal listening sweet spot and stereo monitor coordinates') and names the acoustic models used. It is clearly distinct from the sibling tools (room modes, Schroeder frequency, RT60), though it does not explicitly reference them.

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?

No guidance on when to use this tool versus the sibling calculators, no prerequisites, and no exclusions. The agent must infer the use case entirely from the purpose statement.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Oct 1, 2026
- First observedcalculate_room_modes
- First observedcalculate_rt60_reverb_time
- First observedcalculate_schroeder_frequency
- First observedcalculate_speaker_listening_position

Deploy Server

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

TDQS

A3.7/5.0

Scored 2026-10-01 23:45 across 4 tools

Disambiguation5/5

Each tool addresses a distinct acoustic calculation: room modes, Schroeder frequency, reverberation time, and listening position. There is no overlap in functionality; an agent can easily select the correct tool for a specific acoustic query.

Naming Consistency5/5

All tool names follow a consistent 'calculate_[subject]' pattern (calculate_room_modes, calculate_schroeder_frequency, etc.), making them predictable and easy to identify.

Tool Count4/5

Four tools is slightly on the low side but covers core acoustic room analysis tasks without redundancy. Each tool has a clear purpose, though additional tools for absorption or speaker placement might be expected.

Completeness4/5

The set covers key acoustic calculations including modal analysis, Schroeder frequency, reverberation time, and listening position. However, it lacks tools for other common acoustic tasks like absorption coefficient calculation or speaker placement optimization beyond the 38% rule.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

MakerPortal compute A
ai.makerportal
Deterministic engineering solvers: biquad filter design, room eigenmodes, LLM VRAM fit.
Audio Processing AI & Machine Learning
81
MCPCalc B
com.mcpcalc
MCPCalc gives agents access to a comprehensive library of calculators spanning finance, math, health, construction, engineering, food, automotive, and more. It includes a full Computer Algebra System (CAS) and a grid-based Spreadsheet calculator.
Finance Developer Tools
102
protogen A
io.github.jdhart81
MCP CAD services; bundles with SmartScale (measure to CAD).
Design Tools
62
Worldcastr Remote MCP
io.github.dhardestylewis
Built-environment forecasts, public benchmarks, and permit or zoning readiness through remote MCP.
Real Estate Government Data
1

Related MCP Servers

room-eq-wizard-mcp
Audio Processing Research & Data
brandon-fryslie
A
license
A
quality
B
maintenance
Enables natural language control of Room EQ Wizard for acoustic measurements, analysis, and EQ optimization, with peak/null detection and room-mode analysis.
Updated a month ago (2026-09-22 21:38 UTC)
46
1
MIT
audio-calibration-mcp
Audio Processing Multimedia Processing
daredoole
A
license
C
quality
B
maintenance
Enables local-first, cross-platform audio calibration workflows combining REW-guided measurement, conservative EQ analysis, DSP export/apply adapters, and measured post-change verification.
Updated 4 days ago (2026-10-17 09:56 UTC)
101
7
MIT
EvoBurrow MCP
Audio Processing Home Automation & IoT
daredoole
A
license
Not graded
quality
A
maintenance
Provides a control room for inspecting A1 Evo AcoustiX artifacts, operating REW measurement workflows, coordinating calibration presets, and making allowlisted Denon/Marantz receiver changes with backups and verification.
Updated 4 days ago (2026-10-17 09:29 UTC)
7
MIT
Magic Master MCP
Audio Processing Multimedia Processing
denisok-ai
A
license
A
quality
B
maintenance
Enables AI agents to master audio tracks to target LUFS/True Peak levels, remove Suno/Udio AI fingerprints, and retrieve mastering passports via a hosted MCP server.
Updated 7 days ago (2026-10-14 13:40 UTC)
11
43 npm
2
MIT

acoustic-room-mode-radar

Capabilities & Tools Included

1. calculate_room_modes

2. calculate_schroeder_frequency

3. calculate_rt60_reverb_time

4. calculate_speaker_listening_position

Quick Start

Running directly via npx

Claude Desktop Integration

Cursor Integration

Specification Authority & Verification

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `calculate_room_modes`

2. `calculate_schroeder_frequency`

3. `calculate_rt60_reverb_time`

4. `calculate_speaker_listening_position`