Skip to main content
Glama

retroarch_input_release

Release latched RetroPad buttons for a RetroArch player to undo a previous press and prevent indefinite button hold. Pair each press with a release to control game input state.

Instructions

PURPOSE: Release (latch up) one or more previously pressed RetroPad buttons for a player. USAGE: Counterpart to retroarch_input_press — every press must eventually be paired with a release (or retroarch_input_release_all), because the receiver latches state indefinitely. Releasing a button that is not pressed is harmless. BEHAVIOR: 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. Fire-and-forget UDP — no acknowledgement. RETURNS: 'Released BUTTONS (player N)' — UDP-send confirmation only.

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.
Behavior5/5

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

With no annotations provided, the description fully discloses behavioral traits: latching (no auto-release), one datagram per frame, UDP transport with specific config requirements, fire-and-forget semantics, and no acknowledgment. This is comprehensive and goes far beyond the basic 'release button' expectation.

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?

The description is organized into labeled sections (PURPOSE, USAGE, BEHAVIOR, TRANSPORT, RETURNS), making it skimmable. It is detailed but each sentence adds necessary context for the complex UDP/latching behavior. Slightly verbose due to repetition of the latching rule, but the structure prevents confusion.

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?

The description covers prerequisites (RetroArch config settings), transport specifics (UDP address/port), behavioral caveats (latching, one datagram per frame), and return value explanation. For a tool with no output schema and no annotations, this is fully complete for an agent to understand and invoke it correctly.

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?

The input schema already describes both parameters (player and buttons) with details like case-insensitivity and range for player. The description adds a note that releasing unpressed buttons is harmless, but this is behavioral rather than parameter-level. Since schema coverage is 100%, the description contributes no critical parameter semantics beyond the 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 purpose is explicitly stated: 'Release (latch up) one or more previously pressed RetroPad buttons for a player.' This clearly identifies the action and resource, and it distinguishes itself from siblings by naming retroarch_input_press and retroarch_input_release_all as related tools.

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?

USAGE explicitly frames this tool as the counterpart to retroarch_input_press and instructs that every press must be paired with a release or release_all. It also notes that releasing an unpressed button is harmless, providing clear guidance on when to use this tool versus alternatives.

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