Built for agents, not bolted on
One ask, three ways to run it: screenRIG, a signage platform with an MCP server bolted on, and building it yourself. Two run the same bakery job side by side, and a row of hands counts every step that lands back on you. The third is still building its first Player.
Film / Built for agents, not bolted on
2:00
vs. a signage platform with an MCP server bolted on
How is this different from human-oriented signage SaaS?
Most signage platforms were built for a person in an editor. Bolt an MCP server on and an agent can drive the editor; the rest of the job still lands on a person. screenRIG was built for the agent to run, from the control plane up. People can watch and edit pages in the dashboard.
- Person
- Editor
- Screens
Agent, through an MCP server bolted onto the editor
- Agent
- Control plane
- Screens
People watch and edit pages in the dashboard
| Where it shows | Signage + MCP server | screenRIG |
|---|---|---|
| Setting up a screen | Varies. Some need a person to sign up and hand the agent a key; others let the agent open a one-screen free account. | Your agent enrolls the project, pairs the screen from its code, and goes straight to content. |
| Making the content | Built in the editor, from its templates. | Your agent prepares media, slides and web apps. People can edit pages in the dashboard. |
| When something fails | An error written for a person, who works out the fix. | A stable code and what to do next, often the exact command. A retried write returns the first result. |
| What done means | Saved or rendered on the server, sometimes with a preview of what should be showing. | The Player confirms playback; a screenshot helps inspect the screen. |
| Pricing | Per screen, or a flat plan with a screen cap. A free account usually covers one screen. | screenRIG is free. Pay only if you want more. There is no per-screen fee. |
Platforms differ. Test yours: run one real task through its MCP server with no one helping, and count the steps a person still does. Five questions to ask.
vs. building it yourself
Why not build the stack myself?
You can. Then your team owns everything a screen needs to keep playing, on every device, for as long as it’s on the wall. On screenRIG it’s already running, and your agent drives it through one plugin.
- Web / PWA
- Android
- Amazon Signage Stick
- Apple TV
- macOS
- Windows
- Linux
- Raspberry Pi
- BrightSign
| What a screen needs | Build it yourself | screenRIG |
|---|---|---|
| Pairing and access | Device enrollment, credentials and revocation. | The screen shows a code, and your agent pairs it to the project. |
| Delivery and offline replay | Downloads, retries and a cache on every device. | Each Player caches media and replays it locally, offline included. |
| Media formats | Transcoding for every decoder you support. | The CLI converts images and video before upload. |
| Health and recovery | Monitoring and remote fixes for screens nobody is near. | Health reports, offline events, remote reboot and display power. |
| Proof of play | Screenshots, play logs and the reports built on them. | Verified publishing, screenshots and per-play records with CSV export. |
| Kiosk apps | Hosting and versioning for web apps. | Immutable releases on their own origin, pinned per playlist. |
| State and events | A data store and an event pipeline for interactive screens. | Key/value state that survives releases, named events and signed webhooks. |
Choose something else when owning the screen runtime is the point. Review the capabilities.
From the control plane up
What agent-native means
An API, a CLI or an MCP server can be added to any product. Agent-native is how the product behaves when an agent runs it with no one watching: what each command returns, how failures recover, and how the agent proves the result.
All eight properties
The agent is the operator. Enrollment creates the project. Once the screen is paired, your agent goes straight to content. Your dashboard invitation arrives by email; nothing waits on it.
A machine-first control plane. Commands answer in JSON with a request ID, or an error with a stable code. The agent reads its own permissions and each Player’s capabilities before it acts.
Author locally, deploy remotely. The CLI converts media, renders slides and packs web apps on the agent’s machine. The agent checks the result, then uploads it.
Errors designed for recovery. Every error says what was wrong and what to do, often with the exact next command. A stale write returns the current revision.
Safe retries, partial progress. Writes carry idempotency keys, so a rerun returns the first result. Fleet commands report each screen, and the agent retries only failures.
Verify what is actually playing. Assigned and playing are different states. Publishing says why a screen isn’t playing yet; a screenshot helps inspect the screen.
A physical deployment target. A coding agent’s web app becomes an immutable release on its own origin, pinned in a playlist and checked on the screen.
Dashboard for visibility, agent for operation. People watch screens, playback, usage and activity, take screenshots, and edit pages and playlists. The agent can create and publish content too.
Can an agent use my existing signage system?
Run one real task through it, end to end, with no one helping. Count the steps that still need a person, and check how it’s priced. If it answers yes to all five, keep it.
- 01
Can your agent discover the tools it needs?
- 02
Can it use authorized access without a person pasting credentials?
- 03
Can it publish the content you actually show, including video and apps?
- 04
Can it update content safely without breaking what’s on screen?
- 05
Can it verify what played, with a screenshot or playback record?
More comparisons
Try it on your actual screen
Pick a real menu, video or kiosk app. Install the official plugin and the Player. Tell your agent to publish it, then check the screenshot and playback records. screenRIG is free. Pay only if you want more.