Skip to main content
Glama
Sign In

clousd-mcp

by io.github.Clousd-Android
OverviewDiscussionsAdmin

observe

Read-only

Look at the phone yourself: a fresh screenshot, the app on screen and (with_text) every labelled or tappable element with a number. Act on an element by its number (act element=N); coordinates, when needed, are in this image's pixels.

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

Input Schema

NameRequiredDescriptionDefault
deviceYesDevice from devices: its name, its label from the dashboard (e.g. "Pixel 7 #3") or its number
numbersNodraw the element numbers on the screenshot
with_textNoalso list the elements (numbered, centres in image pixels)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / device / description
      Previous value: -"Device from devices (op=list): its name, its label from the dashboard (e.g. \"Anna IG\" or \"Pixel 7 #3\") or its number"New value: +"Device from devices: its name, its label from the dashboard (e.g. \"Pixel 7 #3\") or its number"
  2. Changed1 schema field changed
    • changedInput schema / properties / device / description
      Previous value: -"Device name from devices (op=list), e.g. dev_04f2"New value: +"Device from devices (op=list): its name, its label from the dashboard (e.g. \"Anna IG\" or \"Pixel 7 #3\") or its number"
  3. Changed3 schema fields changed
    • addedInput schema / properties / device / description
      Added value: +"Device name from devices (op=list), e.g. dev_04f2"
    • addedInput schema / properties / numbers
      Added value: +{
+  "default": true,
+  "description": "draw the element numbers on the screenshot",
+  "title": "Numbers",
+  "type": "boolean"
+}
    • addedInput schema / properties / with_text / description
      Added value: +"also list the elements (numbered, centres in image pixels)"
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description contributes beyond that by stating the screenshot is fresh on each call (no caching) and that the coordinate space belongs to the returned image, which matters before issuing an act. It does not mention latency or failure modes for an unavailable device.

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

Conciseness5/5

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

Two sentences, front-loaded with the core action, with the follow-up (act by number, pixel coordinates) packed into the second. Nothing is redundant.

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 carries the burden of describing the return value, and it does: a screenshot plus (with_text) a numbered element list with centres in image pixels. Only error/edge behavior for a missing device is unaddressed.

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 100%, so the baseline is 3; the description adds real meaning by explaining the purpose of numbering (element=N addressing) and by tying 'coordinates' to this specific image's pixel space, which the schema does not convey.

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

Purpose5/5

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

The description uses a concrete verb and resource ('Look at the phone yourself: a fresh screenshot, the app on screen') and explicitly names the counterpart action ('act element=N'), so an agent can distinguish observe from act without opening either schema.

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?

It establishes the workflow context: capture the screen here, then act on a numbered element via act, and use this image's pixel coordinates. There is no explicit when-not guidance, but the division of labour with act is clear.

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

All clousd-mcp toolsInspect
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