Manage your screens from an AI assistant
ScreenTinker runs a Model Context Protocol server. Point Claude — or any MCP client — at your instance and ask for what you want in plain English, instead of clicking through a dashboard.
What this actually is
The Model Context Protocol is how an AI
client discovers and uses tools on a server. ScreenTinker publishes one at /mcp on every
instance — hosted or self-hosted, no add-on and no separate service. An assistant connected to it
can see your screens and act on them, and you talk to it the way you would talk to a colleague:
- “Which screens are offline?”
- “Put this YouTube video on the lobby TV.”
- “Did the autumn campaign actually play last week, and on how many screens?”
- “Turn the café screens off — we’re closed Monday.”
No other digital signage CMS does this today. It is the same argument as the rest of the product: the API is public and documented, so anything we can build on it, you can too.
Step 1 — create a token
In the dashboard: Settings → API tokens. The value is shown once.
Start with a read token. The tool list an assistant sees is filtered by
the token’s scope, so a read token means the assistant is not merely refused when it tries to change
something — it never sees that the tool exists. Move to write when you want it making
changes, and full only if you want it able to delete.
Step 2 — connect your client
The endpoint is https://your-server/mcp, and it authenticates with the same header as the
REST API:
Authorization: Bearer st_...In Claude Desktop, add it as a remote MCP server with that URL and header. Other clients differ in where you paste the two values, but those are the only two.
⚠️ The token is a credential in a config file on your machine. Keep it to
read unless you need more, and revoke it in the dashboard the moment a laptop goes missing
— a leaked token reaches one workspace and no administrative surface at all, by design, but that is
still your content.
Step 3 — ask it something
“Which of my screens are offline?” calls one tool and gets back the count plus the names and how long each has been dark — because “three offline” is not actionable and “three offline: Lobby, Café, Window since 09:12” is.
What it can do
Twenty-one tools, chosen rather than generated. The API has 133 operations and wrapping all of them would make the list unusable — an assistant gets measurably worse at picking the right tool as the list grows — so these are shaped around what people ask for.
| Scope | What the assistant can do |
|---|---|
read | List and inspect screens, playlists, content, groups and schedules. Fleet health. Proof-of-play and uptime reports. |
write | Everything above, plus: add YouTube videos and web pages, build and publish playlists, assign them to a screen or a group, send refresh / screen on / screen off / volume commands, rename a screen. |
full | Everything above, plus removing items from a playlist. |
⚠️ Playlist edits are a draft. Screens keep playing the last published version until the assistant publishes, and the tool descriptions say so — an agent that adds items and stops has changed nothing anyone can see.
How it is kept safe
The MCP server is a client of our own public API, not a second way into the database.
Every tool call is an HTTP request back into the same API you could call with curl, carrying
your token — so workspace isolation, the scope gate and the rate limits apply to an assistant exactly
as they apply to you. There is no second copy of the permission model to drift out of step with the first.
What a token cannot do does not change either: it is bound to one workspace and can never reach platform administration, billing, account management or provisioning. An assistant holding your token has exactly your API access and not one endpoint more.
Self-hosted instances
It ships with the server, so a self-hosted instance has it at https://your-server/mcp with
nothing to install and no traffic through us. Your content, your model access, your box.