Skip to main content
Glama
Sign In
NexusAndroid

NexusAndroid

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

look

Read-onlyIdempotent

Inspect an Android phone screen as a numbered UI element list with optional screenshot, text query, and region zoom to identify and interact with on-screen controls.

Instructions

See the phone screen: numbered elements [N] (role, text, states, center @x,y), and an image when needed. show: auto (default, text first: the list alone; the image is joined when the screen has no readable element), both (list and image), image, elements, none. query: list only the elements containing this text. region [x1,y1,x2,y2]: zoom (pixels of the last full image). marks (show=both): [N] numbers drawn on the image, with a thin outline of each element (auto = all when few, else unnamed elements only; all; none). Unreadable UI tree: the image is not sent (codes not masked), unless confirm=true, set only with the user's agreement.

Input Schema

NameRequiredDescriptionDefault
showNoauto
marksNoauto
queryNo
regionNo
confirmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.10
    • changedInput schema / properties / show / default
      Previous value: -"both"New value: +"auto"
    • changedInput schema / properties / show / enum
      Previous value: -[
-  "both",
-  "image",
-  "elements",
-  "none"
-]New value: +[
+  "auto",
+  "both",
+  "image",
+  "elements",
+  "none"
+]
  2. Changed1 schema field changedv0.9.3
    • addedInput schema / properties / marks
      Added value: +{
+  "default": "auto",
+  "enum": [
+    "auto",
+    "all",
+    "none"
+  ],
+  "title": "Marks",
+  "type": "string"
+}
  3. Changed1 schema field changedv0.4.1
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": false,
+  "title": "Confirm",
+  "type": "boolean"
+}
  4. First observedv0.3.1

TDQS

A4/5.0
Behavior4/5

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

Annotations cover the safe-read profile (readOnly, idempotent, non-destructive), so the description's added value is the privacy behavior: 'Unreadable UI tree: the image is not sent (codes not masked), unless confirm=true, set only with the user's agreement.' That is a non-obvious side effect an agent must know. It doesn't state cost/latency of image capture or how large element lists are returned.

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?

Dense but front-loaded: the core action comes first, then mode options, then modifiers, then the exceptional case. The telegraphic phrasing ('zoom (pixels of the last full image)', 'auto = all when few, else unnamed elements only') is compact but occasionally requires re-reading, which keeps it from a 5.

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?

With no output schema, the description does describe the return shape (numbered element list, image, marks drawn on the image), which is what an agent needs to plan a call. It is missing only edge detail on the 'none' mode and on how very large element lists are returned.

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

Parameters4/5

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

Schema coverage is 0%, so the description carries the full load and largely does: every enum value of show is explained, marks is described including the outline behavior and what 'auto' means, query is defined as a text filter, region is given as [x1,y1,x2,y2] in pixels of the last full image, and confirm's precondition is stated. Minor gaps remain (coordinate origin, behavior for out-of-range regions, show=none semantics).

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 clause gives a concrete verb and resource: 'See the phone screen', then specifies the return format as numbered elements [N] with role, text, states and center coordinates plus an optional image. That is far more specific than the bare name 'look'. It does not name or contrast any sibling (e.g. capture, act), so it stops short of a 5.

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?

Mode selection is explicitly guided: 'auto (default, text first: the list alone; the image is joined when the screen has no readable element)', plus the explicit alternatives both/image/elements/none and 'query: list only the elements containing this text'. The conditional for confirm ('set only with the user's agreement') is a real usage rule. It still lacks explicit when-not-to-use-this-tool vs siblings guidance.

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

Deploy Server

Other Tools