MCP + integration / 9 min read
What an MCP server for internet radio should actually do
A useful radio MCP server is not a chat wrapper around every API endpoint. It gives assistants a small, legible set of tools that match real station jobs and preserve operator control.
The Model Context Protocol gives an AI client a standard way to discover and call tools exposed by another system. For an internet radio platform, that can make natural-language work much more reliable than asking an assistant to click through an unfamiliar dashboard.
The protocol is only the connection layer. The quality of a radio integration depends on the tools, permissions and operating states behind it.
A server that exposes hundreds of raw database-shaped actions may be technically complete and operationally confusing. A useful MCP server exposes the jobs a broadcaster recognises.
Start with station questions, not API tables
An operator rarely thinks, “List playlist schedule rows filtered by status.” They ask:
- What is on air?
- Is tomorrow ready?
- Which hours have no programming?
- Find the clean versions of these tracks.
- Build a draft for Friday night.
- Why did the live show return to AutoDJ?
- What changed since yesterday?
Those questions suggest a compact tool catalogue.
Station state
Read-only tools can report:
- on-air source and current item;
- upcoming programming;
- AutoDJ readiness;
- live-source connection state;
- listener-delivery health;
- plan, storage and team allowances;
- warnings that need an operator’s attention.
The response should be structured enough for the client to reason over and concise enough for a person to inspect.
Media discovery
A find_media tool should search within the authorised station and return stable identifiers alongside human-readable details such as title, artist, duration, tags and readiness.
It should not dump the entire media library into the model context. Tool inputs can carry filters; tool results can be paginated and limited. The assistant can refine its search when needed.
Draft programming
Draft tools can create or modify proposals:
draft_playlist;draft_programme;draft_schedule;suggest_gap_fills;review_programming_conflicts.
The key word is draft. The tool result should identify the created draft, assumptions, exclusions and unresolved issues.
Diagnostics
A radio platform knows more than “healthy” or “unhealthy.” A useful diagnostic can explain the path:
- Was the intended source connected?
- Was audio reaching the streaming service?
- Was the public mount available?
- Could the listener endpoint return audio?
- Was the player receiving current metadata?
The agent should receive a safe summary and remediation options, not unrestricted shell access to streaming infrastructure.
Keep consequential tools narrow
Some actions may be appropriate through MCP, but only with explicit controls.
A publication tool should accept a particular reviewed draft—not an unconstrained block of schedule data—and the server should re-check:
- the authenticated identity;
- organisation membership;
- station scope;
- role;
- current plan constraints;
- draft version;
- conflicts introduced since review;
- required confirmation.
The same caution applies to deleting media, switching live sources, rotating credentials and changing workspace access.
MCP does not replace application security. A client calling a structured tool is still an external request that must pass the platform’s normal authorisation and validation.
Choose the correct boundary for public and authenticated tools
Not every tool needs station access.
Public tools can safely answer questions using published product information:
- compare plans;
- recommend a plan from stated needs;
- explain the external live-broadcast workflow;
- check whether a proposed migration fits published limits;
- open a normal trial route.
Those tools help an agent understand the product without exposing customer data. A trial-navigation tool should not create a subscription or charge a card.
Authenticated tools belong behind an organisation-scoped connection. Tokens should be created by an authorised operator, limited to the intended workspace and revocable from the normal account surface.
Return evidence with the answer
Tool results should help the user verify the agent’s conclusion.
Instead of:
Tomorrow is ready.
Return:
- schedule window checked;
- number of programmes;
- unfilled minutes;
- media-readiness warnings;
- relevant draft or programme identifiers;
- time of the underlying observation.
The assistant can still explain the result conversationally, but the statement is anchored in observable station state.
Design for partial failure
Radio work is full of incomplete inputs. A referenced track may not exist. A presenter may not have uploaded a show. A schedule can change while an agent is preparing a draft.
Tool contracts should represent partial outcomes explicitly:
status: completed_with_warnings;- missing items;
- skipped operations;
- stale version;
- retryable versus permanent errors;
- next safe action.
This prevents an agent from translating “12 of 15 items prepared” into “the programme is ready.”
MCP and WebMCP are complementary
An authenticated server MCP connection is the durable route for remote or headless work. It can be available to an assistant without an SGNL page remaining open.
WebMCP serves a different purpose. On a compatible browser, a page can declare tools that help a browser agent use the current experience reliably. It is useful for product questions and visible in-page work.
The two surfaces should share concepts and policy, but they do not need identical catalogues. Public browser tools can be intentionally narrow. Authenticated remote tools can operate within the exact station scope granted by the owner.
A sensible first client session
An operator connecting an assistant should be able to try a sequence like:
- “List the stations I can access.”
- “Show me tomorrow’s programming warnings for Station A.”
- “Find suitable media for the 14:00 gap.”
- “Prepare a draft fix but do not publish it.”
- “Explain every proposed change.”
- “Open the draft for my review.”
That sequence proves discovery, permission scope, structured inspection and safe preparation before publication is considered.
The product test
An MCP server for internet radio is successful when it makes station work clearer, not merely when an AI can call it.
The test is whether:
- an operator can predict what each tool will do;
- results are attributable and reviewable;
- permissions remain effective;
- the assistant handles missing information honestly;
- publication cannot happen silently;
- ordinary dashboard users and agent users see the same authoritative state.
SGNL Desk’s authenticated MCP endpoint is documented at AI agents and MCP. The public page also explains how browser WebMCP tools differ from the remote connection.