Screen for AI

Get screen status

device_get_status

Read-onlyIdempotent

Returns safe connection, capability, and display diagnostics for one authorized screen, with its route and support: the tools, security modes, runtime APIs and limits that work on it. android_api, app_version and webview_version are what the screen itself reported (null: not reported, for example by an older app); an old android_api or webview_version means an old browser engine. Its screen_settings say which of the owner's screen options are on and where the owner finds each one in the app (state null: not reported, not off). No tool changes them; the owner changes them on the screen at the where path. The app's Settings pages: Settings › Recovery: Return to Start, Safe mode, Show the last page again, Clear remote content; Settings › Connected agents: Allow connections on this Wi-Fi, This screen on Wi-Fi, Show when an assistant reads answers; Settings › Account: Connect an account, Connection check, Disconnect account; Settings › Display: App brightness, Night hours, Subtle pixel shift, Immersive mode; Settings › Display › Night hours: Use night hours, Starts, Ends, Night brightness, Let the display turn off in these hours; Settings › Wake & lock screen: Keep screen awake, Show over the lock screen, Wake the screen for new pages, Remote wake alerts; Settings › Wake & lock screen › Wake the screen for new pages: Use wake for new pages, Notifications blocked, Reopen by itself; Settings › Home mode: Use Home mode; Settings › About this screen: Screen name, Export support bundle, Beta feedback, Open-source licenses. Settings opens from the screen menu: the round menu button in the bottom-right corner of the screen, then Settings. The same menu has Start, which returns to the built-in Start page, and recent pages. While the phone is locked and the screen shows over the lock screen, Settings first asks the owner to unlock. On screens whose screen_settings.settings_layout is 1 (older app versions) Settings opens from a Settings button at the top right instead. On the gateway route, display follows what the screen last reported (a page, or its Start page) and names no page. When route_diagnostics.current is false, the report came from a previous connection and the current display is unconfirmed. Without a report of a page or the Start page, display is a placeholder.

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": "device_get_status"
  }
}

Input Schema

Name	Required	Description	Default
`device`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

B3.3/5.0

Behavior5/5

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

Beyond the annotations, it discloses important behavior: null means not reported, older android_api or webview_version implies an old browser engine, screen_settings state null means not reported rather than off, settings cannot be changed by tools, locked phones may require unlocking, older settings_layout changes the path, and route_diagnostics.current=false means unconfirmed display. This is unusually rich behavioral context for a read-only diagnostic tool.

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

Conciseness2/5

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

The first sentence is well front-loaded, but the description then becomes a long, unformatted block, including an exhaustive enumeration of Settings pages and options. Much of that detail may help explain screen_settings, but it is far more than an agent needs to select and invoke the tool correctly.

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?

For a diagnostic tool with an output schema, this description covers the important edge cases: null semantics, old app versions, locked-screen behavior, gateway routing, and unconfirmed current display. It is only incomplete in that it does not explain the device parameter, though the output-schema presence reduces the need to describe return fields in prose.

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 the sole required parameter 'device' is never explained in the description. The phrase 'one authorized screen' implies the parameter identifies a screen, but it does not clarify whether it is an ID, name, or another identifier format, nor does it explain authorization expectations beyond that phrase.

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 opening sentence gives a specific verb and resource: it returns connection, capability, and display diagnostics for one authorized screen, including route and support details. It is clearly not a generic device tool, but it does not explicitly differentiate itself from nearby alternatives such as display_get_current.

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

Usage Guidelines2/5

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

The description explains what the result contains but gives no direct guidance on when to call this tool versus alternatives like display_get_current or devices_list. It contains useful behavioral notes, such as 'No tool changes them,' but those are not usage-selection instructions.

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?