Screen for AI

Render HTML on multiple screens

display_broadcast_html

Installs the same self-contained HTML on an explicit list of at least two distinct authorized screens (the device IDs or names of the caller's screens), as one independent display operation per screen. There is no all-screens target. With page_id each screen keeps it as the same page, updated by a later broadcast with that page_id.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "html": "<html>",
      "devices": "<devices>"
    },
    "name": "display_broadcast_html"
  }
}

Input Schema

Name	Required	Description	Default
`html`	Yes
`title`	No
`devices`	Yes
`page_id`	No	The page's name of the caller's choosing, which becomes its view_id. A later send with the same page_id is a new revision shown in that page's place; each revision has its own saved state, which starts empty unless initial_state supplies earlier answers.
`runtime`	No
`ttl_seconds`	No	Seconds the screen shows the page before it returns to its Start page (null: until another page replaces it). It does not keep the display lit: the phone turns its display off after its own screen timeout unless the owner's Keep screen awake setting is on (screen_settings.keep_screen_awake in the screen's status).
`source_label`	No
`initial_state`	No	Saved answers the new page starts with, written once when the screen first admits it, before its scripts run. A new revision of a page (the same page_id) receives no answers from earlier revisions otherwise. Example: the saved state of page_id "bookclub-vote" held values {"book": "Emma"}; the revision sent with page_id "bookclub-vote" and initial_state {"book": "Emma"} reads "Emma" from getState("book") and can show it selected.
`security_mode`	No		normal
`replace_policy`	No		activate_when_healthy
`client_request_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that this writes state (readOnlyHint=false), is non-destructive, non-idempotent, and open-world. The description adds useful detail that each screen receives an independent display operation (implying partial-failure isolation) and requires authorized screens, but says nothing about what a failure on one device means for the rest, how replace_policy/security_mode behave, or TTL interaction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action and the hard constraints (minimum two screens, no all-screens target). The trailing page_id sentence is somewhat redundant with the schema's parameter description and could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with nested runtime objects and security modes, the description covers the core invocation path and constraints but leaves most parameters unexplained. An output schema exists so return values need no coverage, but the behavioral surface of security_mode, replace_policy, and ttl_seconds is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 27% across 11 parameters, so the schema leaves gaps. The description adds real meaning for devices (device IDs or names of the caller's screens), html (self-contained), and page_id revision persistence, but the page_id explanation largely restates the schema's own description, and eight parameters (title, runtime, ttl_seconds, source_label, initial_state, security_mode, replace_policy, client_request_id) get no attention.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource (installs self-contained HTML on an explicit list of screens) plus the scope constraint (at least two distinct authorized screens, no all-screens target). That the minimum is two implicitly separates it from single-screen display_render_html, though the sibling is never named outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear conditions: needs an explicit list of at least two devices (IDs or names) belonging to the caller, and there is no all-screens variant, which rules out the most likely misuse. It stops short of naming the single-screen alternative or any exclusion such as when to prefer display_show_template.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Screen for AI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?