EAS: What If the Problem Is not Software But the Lack of MCP?
[July 2025] Getting emergency information to a community is an important function of broadcasters. But today we know there are many possible ways to disseminate the information, including streams, cell phones, etc. Can broadcasters leverage their EAS systems to serve the community more effectively.
In his recent article Software EAS: Unanswered Questions and Unwise Haste, Richard Rudman calls for restraint in the shift to software-based Emergency Alert System platforms.
His concerns are valid: EAS is a life-safety infrastructure, and reliability cannot be sacrificed in the name of modernization.
But I believe we are asking the wrong question.
WHAT ARE WE MOVING TO?
The issue is not whether we move from hardware to software, it is how we move, and what control framework we put in place.
What EAS truly needs is not more fear or delay. It needs a resilient, transparent, vendor-agnostic control layer: A Message Control Protocol (MCP) built specifically for broadcast alerting.
And I believe now it is time we build it.
THE RISK CAN BE HANDLED
Mr. Rudman is right about the risk – but we can address it.
Richard is correct that EAS must function during the worst-case scenarios – power failures, cyber events, and natural disasters. He is also right that general-purpose IT systems vary wildly in configuration and reliability.
But the solution is not to freeze innovation. Rather, the solution is to wrap software EAS implementations and information dissemination in a rigorous, open, testable control protocol that manages:
- Ingestion
- Delivery
- Redundancy
- Auditing
- Platform diversity
- Failure handling
At KAZM, we have already field-tested these points.
MCP: A MODERN FRAMEWORK FOR A MODERN EAS
At KAZM, we have implemented a real-world Message Control Protocol layer that sits between our certified DASDEC CAP receiver and our multiple delivery platforms.
Here is how it works:
- CAP Alert Ingest via our DASDEC receiver.
- MCP Engine (built on n8n) parses the alert, logs it, and determines severity.
- An AI Agent rewrites the alert for clarity and TTS conversion.
- Voice Generation is handled by ElevenLabs.
- Multi-path Delivery routes the alert to:
- Over-the-air broadcast (via MegaSeg and AudioHijack).
- Streaming (Live365 + Icecast).
- Website alert box.
- Local signage.
- Internal operations Slack channel.
- SDR Nodes in multiple cities validate that the EAS alert was actually received and aired.
- Audit Logs and Alert Confirmations are posted directly into Slack for tracking and compliance.
This MCP layer does not just automate, it validates, reacts, and recovers – it feeds the community with critically needed information wherever they are listening or ready to listen.
WHAT RUDMAN IS ASKING FOR WE HAVE BUILT
Richard’s concerns are reasonable.
In fact, every bullet point he raises (patching, certification, cyber risk, platform failure, human readability) is precisely what a proper MCP system exists to solve.
MCP can define:
- A JSON schema for alerts.
- Webhook or REST-based inputs/outputs.
- Alert scoring.
- A compliance profile.
- Integration paths for OTA, stream, signage, and more.
- Failure recovery workflows.
- Alert redundancy via fallbacks and delayed replays.
- Verification via SDR or passive monitoring nodes
Bottom line: we are not replacing compliance we are adding observability – and the confidence that the community knows where to get information in an emergency.
WHY WAIT FOR SOMEONE ELSE TO BUILD IT?
Let us be honest: waiting for FEMA or a manufacturer to propose MCP would take a decade.
That is why we plan to open-source our internal schema and MCP stack. Were also exploring a hosted version for small-market stations who need EAS resilience but cannot afford full-time engineering staff.
We want to work with people like Richard, not against them, to build a system that answers the very questions he is asking.
THE PATH FORWARD: CAUTIOUS, YES. BUT BOLD.
EAS cannot be frozen in 1996 forever.
Purpose-built hardware will continue to serve its role, but the future is modular, multi-platform, and auditable. MCP is the discipline EAS needs. It is the rigorous wrapper that makes software safe.
So let us stop framing software EAS as a binary risk. Let us build the protocol that ensures every message is:
✅ Ingested
✅ Verified
✅ Voiced
✅ Routed
✅ Logged
✅ Confirmed in the air chain
That is not unwise haste. That is smart resilience.
– – –
Charles Helstein is the Owner and Chief Engineer of KAZM AM/FM Mellow Mountain Radio in Sedona AZ. He can be reached at: chuck@mellowmountainradio.com
– – –
Would you like to know when more articles like this are published? It will take only 30 seconds to
click here and add your name to our secure one-time-a-week Newsletter list.
Your address is never given out to anyone.