Skip to main content
Glama
Sign In
android-mcp

android-mcp

by ibrahimali111
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

android_tap

Simulate a tap at exact screen coordinates (x, y) on Android devices, Waydroid containers, or AVD emulators to automate UI interactions.

Instructions

Tap on specific screen coordinates (x, y).

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": {
      "x": "<x>",
      "y": "<y>"
    },
    "name": "android_tap"
  }
}

Input Schema

NameRequiredDescriptionDefault
xYesX coordinate in pixels
yYesY coordinate in pixels

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, yet it discloses nothing about requiring an active device/session, whether the tap waits or returns immediately, or what happens on out-of-bounds coordinates. For a UI-interaction tool with zero annotation coverage this is a significant gap.

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?

A single front-loaded sentence with no filler or redundancy. It is efficiently sized, though so terse that brevity shades into under-specification.

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

Completeness2/5

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

For a touch-input primitive with no annotations and no output schema, the description omits anything about connection requirements, failure behavior, or return values. An agent cannot tell from this text alone what preconditions the call needs.

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 100% (both x and y are documented in pixels), so the schema already does the heavy lifting. The description merely restates '(x, y)' and adds no detail such as coordinate origin or screen-resolution dependence, matching the baseline 3 for high-coverage schemas.

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?

States a clear verb (tap) and resource (screen coordinates), so the basic action is unambiguous. However, it does not differentiate itself from the sibling android_click_by_text, which is the obvious alternative for the same intent, so it falls 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 Guidelines2/5

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

There is no guidance on when to tap coordinates versus using android_click_by_text, nor any prerequisite such as an active device connection or needing a screenshot first. The agent is left to infer usage entirely.

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