Skip to main content
Glama
dmang-dev

mcp-dolphin

dolphin_set_wiimote_acceleration

Set the Wii Remote's accelerometer values (in g) for one frame, enabling raw motion input in games like Wii Sports bowling swings.

Instructions

PURPOSE: Set the Wii Remote's accelerometer reading on the given port. USAGE: Use for games that read raw accelerometer data — Wii Sports bowling/golf swings, Mario Galaxy's shake-to-spin, anything that doesn't go through the higher-level swing/shake/tilt helpers (deferred to a future release). Units are roughly g (Earth gravity ≈ 1.0); a Remote held still and pointing forward typically reads about (0, 1, 0). For a single-frame impulse, set the value then dolphin_frame_advance(1) then reset to neutral. BEHAVIOR: DESTRUCTIVE to accelerometer state for the addressed port. ClearOn::NextFrame semantics — set persists for one render frame only. RETURNS: 'Set Wii Remote port N accel to (x, y, z)'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
portNoWii Remote port (0-3, default 0).
xYesAccel X (roughly g).
yYesAccel Y (roughly g; ~1.0 for level-and-still pointing forward).
zYesAccel Z (roughly g).

Implementation Reference

  • src/tools.ts:353-371 (registration)
    Tool schema and description registration in the TOOLS array. Defines name, purpose, input schema (port, x, y, z floats), and ClearOn::NextFrame behavior.
    {
      name: "dolphin_set_wiimote_acceleration",
      description:
        "PURPOSE: Set the Wii Remote's accelerometer reading on the given port. " +
        "USAGE: Use for games that read raw accelerometer data — Wii Sports bowling/golf swings, Mario Galaxy's shake-to-spin, anything that doesn't go through the higher-level swing/shake/tilt helpers (deferred to a future release). Units are roughly g (Earth gravity ≈ 1.0); a Remote held still and pointing forward typically reads about (0, 1, 0). For a single-frame impulse, set the value then dolphin_frame_advance(1) then reset to neutral. " +
        "BEHAVIOR: DESTRUCTIVE to accelerometer state for the addressed port. ClearOn::NextFrame semantics — set persists for one render frame only. " +
        "RETURNS: 'Set Wii Remote port N accel to (x, y, z)'.",
      inputSchema: {
        type: "object",
        required: ["x", "y", "z"],
        properties: {
          port: { type: "integer", minimum: 0, maximum: 3, description: "Wii Remote port (0-3, default 0)." },
          x:    { type: "number", description: "Accel X (roughly g)." },
          y:    { type: "number", description: "Accel Y (roughly g; ~1.0 for level-and-still pointing forward)." },
          z:    { type: "number", description: "Accel Z (roughly g)." },
        },
        additionalProperties: false,
      },
    },
  • Handler case in the CallToolRequestSchema switch. Extracts port/x/y/z from arguments, calls the Dolphin bridge via dol.call with the method 'controller.set_wiimote_acceleration', and returns a confirmation string.
    case "dolphin_set_wiimote_acceleration": {
      const port = (p.port as number | undefined) ?? 0;
      const x = p.x as number, y = p.y as number, z = p.z as number;
      await dol.call("controller.set_wiimote_acceleration", [port, x, y, z]);
      return ok(`Set Wii Remote port ${port} accel to (${x}, ${y}, ${z})`);
    }
  • Python bridge helper function that unpacks the positional params (port, x, y, z) and calls Felk's controller.set_wiimote_acceleration API inside Dolphin.
    def _set_wiimote_acceleration(p):      controller.set_wiimote_acceleration(p[0], p[1], p[2], p[3]); return None
  • Maps the RPC method string 'controller.set_wiimote_acceleration' to the _set_wiimote_acceleration Python function in the HANDLERS dict.
    "controller.set_wiimote_acceleration":     _set_wiimote_acceleration,
  • Input schema definition for the tool requiring x, y, z as numbers and port as optional integer (0-3, default 0).
      inputSchema: {
        type: "object",
        required: ["x", "y", "z"],
        properties: {
          port: { type: "integer", minimum: 0, maximum: 3, description: "Wii Remote port (0-3, default 0)." },
          x:    { type: "number", description: "Accel X (roughly g)." },
          y:    { type: "number", description: "Accel Y (roughly g; ~1.0 for level-and-still pointing forward)." },
          z:    { type: "number", description: "Accel Z (roughly g)." },
        },
        additionalProperties: false,
      },
    },
Behavior5/5

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

With no annotations, the description fully covers behavior: it declares 'DESTRUCTIVE to accelerometer state', explains 'ClearOn::NextFrame' semantics, and describes the return format. This gives the agent complete understanding of side effects and lifecycle.

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 headings (PURPOSE, USAGE, BEHAVIOR, RETURNS) and is appropriately sized. Every sentence provides essential information without redundancy, earning its place efficiently.

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 complexity, lack of annotations, and no output schema, the description is remarkably complete. It covers purpose, usage guidance, behavioral nuances, parameter semantics, and return format, leaving no critical gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value: it explains units (roughly g), gives a concrete example of neutral reading (0,1,0), and advises on single-frame impulse usage. This goes well beyond the schema's minimal descriptions.

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 clearly states it sets the Wii Remote's accelerometer reading for a given port. It distinguishes from siblings by explicitly mentioning raw accelerometer data and contrasting with higher-level helpers. Examples like Wii Sports bowling/golf swings and Mario Galaxy's shake-to-spin solidify the purpose.

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?

The description explicitly says 'Use for games that read raw accelerometer data' and lists specific scenarios. It also tells when not to use it by noting that other features are 'deferred to a future release', providing clear context for selection.

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/dmang-dev/mcp-dolphin'

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