Skip to main content
Glama

retroarch_input_tap

Tap RetroPad buttons with a configurable hold duration for menu navigation and gameplay inputs, automatically pressing and releasing each button.

Instructions

PURPOSE: Press buttons, hold them for a duration, then release them — the everyday building block for menu navigation and normal play. USAGE: Use while emulation is RUNNING (state 'playing' per retroarch_get_status). The default 100 ms hold spans ~6 frames at 60 fps, comfortably above the one-datagram-per-frame application delay and typical game input-polling windows. For frame-accurate work while PAUSED, do not use this tool — compose retroarch_input_press / retroarch_frame_advance / retroarch_input_release manually, because this tool's hold is wall-clock and a paused emulator never samples it. BEHAVIOR: Sends press datagrams, waits hold_ms of wall-clock time, sends release datagrams. Multiple buttons latch over consecutive frames (see below), so a two-button chord is fully held only from the second frame of the hold window onward. Two receiver behaviors govern all input tools: (1) LATCHING — a pressed button stays down until an explicit release; there is no auto-release or keepalive. Always pair presses with releases or use retroarch_input_release_all. (2) ONE DATAGRAM PER FRAME — RetroArch consumes at most one queued input message per emulated frame per player, so N changes sent back-to-back land over N consecutive frames. For frame-accurate scripting: pause, then alternate one input tool call with one retroarch_frame_advance per change. Transport: RetroArch's Network Gamepad receiver over UDP (default 127.0.0.1:55400 + player index; requires network_remote_enable = true AND network_remote_enable_user_p1 = true (per player) in retroarch.cfg, or Settings > Input > Network Gamepad). This is a SEPARATE channel from the NCI command port — enabling Network Commands alone is not enough. RETURNS: 'Tapped BUTTONS for HOLDms (player N)' after the release datagrams are sent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
playerNoPlayer index, 0-based (see retroarch_input_press). Default 0.
buttonsYesRetroPad button names (case-insensitive): b, y, select, start, up, down, left, right, a, x, l, r, l2, r2, l3, r3.
hold_msNoWall-clock hold duration in milliseconds. Default 100 (~6 frames at 60 fps). Minimum 16 (~1 frame); values under ~50 ms risk the game's input poll missing the press entirely on cores that debounce.
Behavior5/5

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

With no annotations provided, the description carries a heavy disclosure burden and fully delivers: it explains wall-clock waits, latching with no auto-release, one-datagram-per-frame consumption, the exact transport channel (UDP Network Gamepad vs NCI), and required config flags. It also explains that multi-button chords are fully held only from the second frame, which is exactly the kind of subtle behavior an agent needs to know.

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?

The description is structured with clear labels (PURPOSE, USAGE, BEHAVIOR, RETURNS) and every sentence adds operational detail. It is longer than average but each sentence earns its place — there is no filler, tautology, or repetition. The RETURNS line even documents the exact success message.

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

Completeness5/5

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

Given the tool's non-trivial interaction model (network transport, latching, frame timing, two receiver behaviors), the description covers prerequisites, configuration, timing, multi-button semantics, and return value. There is no output schema, so the RETURNS section compensates. The only minor gap is what happens on failure, but the sibling list and tool purpose make that acceptable; overall this is complete.

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% and already includes fine parameter descriptions, so this dimension is near baseline. However, the description adds context not in the schema: the default 100 ms hold maps to ~6 frames, minimum 16 ms risks input-poll misses, and player index is 0-based (referencing retroarch_input_press). This is meaningful additional meaning beyond the raw schema.

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 opens with 'Press buttons, hold them for a duration, then release them' — a specific verb+resource+behavior — and distinguishes itself from sibling tools by explaining that this is for normal play/menu navigation while paused frame-accurate work should use press/frame_advance/release manually. This clearly separates it from retroarch_input_press and retroarch_input_release.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It explicitly states when to use (emulation running, state 'playing'), when NOT to use (paused frame-accurate work) and names the alternative composition (retroarch_input_press / retroarch_frame_advance / retroarch_input_release). It also warns about two receiver behaviors (latching and one-datagram-per-frame) and tells users to pair presses with releases or use release_all.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pythoninthegrass/mcp-retroarch'

If you have feedback or need assistance with the MCP directory API, please join our Discord server