Skip to main content
Glama

iamf-sentinel-mcp

An MCP server exposing iamf-sentinel (IAMF conformance validator) and iamf-loom (IAMF packager) to MCP clients — Claude Desktop, Claude Code, and any other agent runtime that speaks the protocol.

IAMF is the Alliance for Open Media's Immersive Audio Model and Formats (v1.1.0). The validator behind this server also reads IAMF v2.0.0 streams, recognises its six profiles and checks their limits, and reads object-based elements and the v2.0.0 rendering settings and checks them; positions over time and parameter blocks remain unvalidated. This server lets an agent validate IAMF files against the spec's conformance rules and compile packaging manifests into inspectable, deterministic plans — without executing anything (execution is a separate, per-launch opt-in — see below).

Code comments throughout cite an internal numbered design docset (doc NN), ADRs, and pre-registered expectation labels — DESIGN-NOTES.md explains the notation and indexes every cited document.

Tools

Tool

What it does

Needs toolchain

iamf_validate

Full conformance report on a .iamf / IAMF-in-MP4 file: S-code findings with severities, summary, stream facts. strict promotes WARN to failing.

no

iamf_inspect

Structure orientation: profiles, codec configs (incl. Opus pre-skip), element/presentation/frame counts, OBU trim totals, MP4 edts/elst presence.

no

loom_compile

Compile a Loom manifest (YAML/JSON) to its packaging plan — validate-only. Per-target backend/muxer routing with rationale, or M-code diagnostics.

no

loom_explain

loom explain as text: the compiled plan as its own justification.

no

loom_run

Compile and execute a manifest: encode, mux, measure, and gate every output through the Sentinel validator. Returns per-target outputs (sha256), gate verdicts, measured loudness, and the run-ledger path. Only registered when the server is launched with --enable-run.

yes

Related MCP server: mcp-audit-server

Resources

  • checks://catalog — every S-code check the validator can emit: severity, layer, title, description, related F-register entries.

  • mcodes://catalog — every M-code compile diagnostic the packager can report, with its stable summary (retired codes kept for the record).

  • fregister://catalog — the failure-mode register (F_TO_CHECK.md): the WP1/WP3 failure catalogue mapped to Sentinel checks, as markdown.

Verified platforms. Every push runs this server's test suite on Linux, macOS, and Windows against Python 3.11 and 3.12 — ci.yml is the claim; the matrix is the evidence. Two boundaries come with it. First, this package is a thin wrapper: a green matrix here says the server behaves on those platforms, not that the conformance logic does — that is gated in iamf-sentinel and iamf-loom by their own matrices. Second, no encoder toolchain is installed in CI, so loom_run's execution path is exercised only through its failure behaviour — that a missing binary yields an actionable error rather than a traceback. Its subprocess half is unverified here by design; iamf-loom owns that claim. The matrix additionally carries a wheel-only leg with no sibling source checkout, which is what pip install iamf-sentinel-mcp actually gives you. Sample-gated tests skip in that environment by design. Nothing here is claimed for a platform that does not have a green leg.

Run

pip install iamf-sentinel-mcp
iamf-sentinel-mcp                # stdio transport, read-only (default)
iamf-sentinel-mcp --enable-run   # additionally registers loom_run (executes)

Claude Desktop / Code config:

{ "mcpServers": { "iamf-sentinel-mcp": { "command": "iamf-sentinel-mcp" } } }

Scope and posture

  • Read-only by default. Without --enable-run, tools parse and compile; nothing is executed, no files are written, no network is touched.

  • Execution is opt-in, per launch. --enable-run registers loom_run, which runs the encoder toolchain as subprocesses and writes files; the Sentinel gate inside loom run stays on by default. A missing toolchain is an actionable error naming the expected binary path. Sentinel L3 rendered-loudness QC remains unexposed.

  • The server is a thin wrapper over the products' public APIs; conformance logic lives in the products, behind their own test gates.

Apache-2.0 (see LICENSE / NOTICE), like everything else in the iamf-sentinel / iamf-loom stack. Support posture: see the core repo's SUPPORT.md.

  • Inseglet — the authoring-side companion: a native REAPER MCP extension for immersive authoring (beds, ambisonics, ADM) whose spatial.export_loom_manifest writes manifests this server's loom_compile / loom_run accept. Run both servers in one agent session for an author → package → validate loop.

Available Tools

4 tools
iamf_inspectA

Summarize an IAMF file's structure without judging conformance.

Returns the container kind, IA sequence header profiles, codec configs (codec, samples/frame, sample rate, Opus pre-skip), element and presentation counts, audio-frame count, and start/end trim totals as parsed from the OBUs — plus, for MP4, whether edts/elst is present. Use iamf_validate for conformance findings; this tool is for orientation.

Inputs: path (required). Returns: object

iamf_validateA

Validate an IAMF file (raw .iamf or IAMF-in-MP4) with iamf-sentinel.

Runs the structural (L1) and semantic (L2) conformance checks — including the container trim-carriage checks S-407/S-408/S-409 — and returns the full report: a summary (PASS/FAIL/ERROR, finding counts, stream facts) and every finding with its S-code, severity, message, and offsets. strict treats WARN findings as failing. profile selects a validation profile (default "generic"). L3 rendered-loudness QC needs the decoder toolchain and is not exposed by this server version.

Inputs: path (required), strict, profile. Returns: object

loom_compileA

Compile an iamf-loom manifest (YAML/JSON) to its packaging plan.

Validate-only: nothing is executed and no files are written. Returns ok=true with a plan summary — per-target backend/muxer routing with the ADR-grounded rationale, and each step's id/kind/tool — or ok=false with the M-code diagnostics exactly as loom compile would report them. variables fills {variable} placeholders (the CLI's --var).

Inputs: manifest_path (required), variables. Returns: object

loom_explainA

Render loom explain for a manifest: the compiled plan as its own justification, in plain text.

The output walks every target: why it routed to its backend/muxer (ADR grounding, F-number references), what every step does and why it exists, and which values resolve only at execution time. Returns ok=true with the text, or ok=false with M-code diagnostics.

Inputs: manifest_path (required), variables. Returns: object

Tool Schema Changelog

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

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 4 tools

    Disambiguation5/5

    Each tool has a clear, distinct purpose: iamf_inspect provides orientation, iamf_validate checks conformance, loom_compile builds the packaging plan, and loom_explain justifies that plan. No two tools overlap in intent, even within the same domain.

    Naming Consistency5/5

    All tool names follow the pattern {domain}_{verb}: iamf_inspect, iamf_validate, loom_compile, loom_explain. The convention is consistent and predictable, making it easy for agents to infer functionality.

    Tool Count5/5

    With only 4 tools, the server is well-scoped and each tool earns its place. The count is neither minimal nor excessive for covering the two core workflows (IAMF analysis and loom manifest compilation).

    Completeness5/5

    The server covers the full intended surface: inspection and validation for IAMF files, and compilation and explanation for loom manifests. There are no obvious dead ends or missing operations within the stated scope.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      This MCP server enables security auditing for MCP configurations and AI agents, including prompt injection testing, data flow tracing, and security policy generation.
      69 npm
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      A fully local, closed-world MCP server that manages, validates, and serves bank-specific ISO 20022 clearing profiles and rule packs, enabling AI agents to discover profiles, fetch them, lint payloads against them, and validate rule-pack definitions.
      4
      30 PyPI
      1
      Apache 2.0