adb-tv-mcp

Overview Schema Source Related Servers Discussions Admin

adb_tap

Send a tap command to an Android TV or Android device screen at specified pixel coordinates (x, y) to trigger touch input at that exact location via ADB.

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

Input Schema

Name	Required	Description
`x`	Yes
`y`	Yes
`serial`	No	device serial (host:port); omit if only one device

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 4, 2026

TDQS

C2.9/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 full burden. It doesn't disclose whether the tap is injected as a single touch, whether it waits for the UI to settle, whether requires an unlocked screen, or what happens on invalid coordinates. Minimal behavioral context is given beyond the action itself.

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?

Extremely concise single sentence with zero waste. The verb-subject-object structure is front-loaded and clear. Could add a bit more context without becoming verbose, but current brevity is appropriate.

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 hardware interaction tool with no annotations and no output schema, the description is thin. It doesn't mention coordinate origin, screen resolution matching, timing behavior, or whether the tap blocks until completion. Given the sibling set includes similar interaction tools (swipe, key, text), more context would help disambiguation.

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 only 33% (the serial param is described in schema, while x and y are not). The description says coordinates are pixels, which adds some meaning for x/y, but doesn't clarify coordinate system origin (top-left) or resolution constraints. Partial compensation.

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?

Description states 'Tap the screen at pixel x,y' with a clear verb (tap) and resource (screen) plus coordinates. It differentiates reasonably from siblings like adb_swipe and adb_key, though it doesn't explicitly distinguish itself.

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?

No guidance on when to use tap vs swipe or key, no mention of coordinate system origin or units (pixel vs dp), and no note about device screen resolution. The serial parameter hint in schema helps but the description itself offers no usage guidance.

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