adb-mcp

by FlashZ

Overview Schema Source Related Servers Discussions Admin

Python

Local

tap

Send a touch event at pixel coordinates (x, y) to automate Android UI interactions.

Instructions

Tap the screen at pixel (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": "tap"
  }
}

Input Schema

Name	Required	Description	Default
`x`	Yes
`y`	Yes
`serial`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 5, 2026

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden and falls well short. It does not mention that a device must be connected, whether the tap is relative to the current screen orientation or the physical display, or which device is targeted when the serial parameter is omitted.

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

Conciseness3/5

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

One short, front-loaded sentence with zero padding — but the terseness here reflects under-specification rather than disciplined concision. It is efficient in size but does not earn its brevity with required detail.

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?

An output schema exists, so return-value explanation is not required. Still, for a 3-parameter device-interaction tool with no annotations, the description omits device targeting, connectivity prerequisites, and differentiation from tap_element, leaving real gaps.

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 parameters have only bare titles. The description does add one genuinely useful semantic: x and y are pixel coordinates. But the optional 'serial' parameter is never explained, so an agent has no idea how to target a specific device among several.

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 specific verb and resource with the operand form: 'Tap the screen at pixel (x, y).' An agent immediately knows this is an input-injection action. However, it does not differentiate itself from the sibling tap_element, which also taps, so the boundary between the two is left to inference.

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 when-to-use guidance at all. With siblings like tap_element, long_press, swipe, and drag, the description never says when raw pixel tapping is preferable to element-based tapping or when it should not be used.

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

Deploy Server

tap