Screen for AI

Show the built-in Start page

display_show_default

Returns an authorized screen to its safe built-in Start page (a clock with the screen's name and status) without deleting its last known good view. The result is an operation: queued until the screen takes it, applied once the screen confirms that it shows its Start page. On a phone-owned screen it takes about as long as a page. Afterwards no page is current: a saved-state read without view_id returns VIEW_NOT_FOUND, and one with a page's view_id still returns that page's saved state.

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": {
      "device": "<device>"
    },
    "name": "display_show_default"
  }
}

Input Schema

Name	Required	Description	Default
`device`	Yes
`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.7/5.0

Behavior5/5

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

Annotations only mark this as a non-readonly, non-destructive, non-idempotent operation; the description goes well beyond them, disclosing that the result is a queued operation applied only after the screen confirms, the rough latency on phone-owned screens, and that the last known good view survives. It also spells out the post-condition state (no page current, VIEW_NOT_FOUND on a stateless read), which is exactly the behavioral context an agent cannot get from annotations.

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?

The action and its safety property are front-loaded, and the follow-on sentences each add distinct information about queuing, latency, and post-state. Slightly dense — the saved-state sentence is long — but no sentence is filler.

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

Completeness4/5

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

An output schema exists and the description still correctly characterizes the return as an operation, so return values need not be restated; the missing piece is any explanation of the two input parameters, particularly client_request_id's purpose for idempotent retries.

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

Parameters2/5

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

Schema description coverage is 0% and neither of the two parameters is explained — device is only obliquely referenced via 'authorized screen', and client_request_id is not mentioned at all. For a tool whose schema carries no parameter documentation, the description should compensate and does not.

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?

The description gives a specific verb and resource — returning a screen to its built-in Start page without deleting the last known good view — plus the distinguishing detail that afterwards no page is current. It does not name a sibling such as page_show or display_show_template to contrast against, leaving the agent to infer the boundary.

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

Usage Guidelines3/5

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

The 'safe built-in Start page' framing implies a reset-to-home use case, and the closing sentences help the agent interpret follow-up reads, but there is no explicit statement of when to choose this over page_show or display_show_template, nor any exclusions.

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?