The design choice worth knowing is that every screen command goes through MoteBus and nothing else — no HTTP fallback, no alternate route. That means a failure surfaces as a failure instead of as a command that appeared to send and never arrived, which is the right trade for anything driving a physical display.
An MCP adapter in front of SmartScreen. Screen commands travel to the display over MoteBus rather than over HTTP, and the adapter resolves which SmartScreen owner to talk to before sending anything. If map resolution, MoteChat, the owner or its reply is unavailable, the call fails visibly — there is no fallback transport that quietly does something else.
- `ss_notify` puts a notification on the screen; `ss_drop` takes it away
- `ss_text` sends text to the display
- `ss_go` sends a screen to a named page or route — `101.tv` dispatches the native WebOS route `page://board?type=dock&q=101.tv`
- `ss_command` carries SmartScreen-owned native command data through a standard `tools/call`, for the cases the named tools do not cover
- `GET /ping` reports process health, and `POST /api/ss` accepts a native `{to,data}` payload for diagnostics
A client that speaks Streamable HTTP, pointed at the `POST /mcp/ss` endpoint and initialising a session before it lists or calls tools; the lab deployment is published at `https://ultra-mcp.u22.ypcloud.com/mcp/ss`. Older clients can use the SSE transport at `GET /sse/ss` when `MCP_TRANSPORT=http+sse`. DNS-rebinding protection is on, so the host you connect from must be in the allowed list — the lab and PD hostnames are not interchangeable.