iamf-sentinel-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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.
|
| 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. |
| 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_explainA | Render 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| checks_catalog | The S-code check catalogue: every check iamf-sentinel can emit, with severity, layer, title, description, and related F-register entries. |
| mcodes_catalog | The M-code catalogue: every compile-time diagnostic iamf-loom can report, with its stable summary. Codes marked retired are kept for the stable-contract record and are no longer emitted. |
| f_register | The failure-mode register (F_TO_CHECK.md): the WP1/WP3 failure catalogue mapped to Sentinel checks — what each F-number means, whether a check fires for it, and its disposition. Markdown. |
TDQS
Scored across 4 tools
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.
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.
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).
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.