Garmin Connect IQ Simulator MCP Server

Overview Schema Source Related Servers Discussions Admin

hold_screen

Simulates a long-press at specified watch touchscreen coordinates to open complications or menus, with configurable hold duration and optional screenshot capture.

Instructions

Long-press at specific coordinates on the watch touchscreen (e.g. to open a watchface complication or menu).

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

Input Schema

Name	Required	Description
`x`	Yes	X coordinate: display pixels or normalized ratio
`y`	Yes	Y coordinate: display pixels or normalized ratio
`wait_ms`	No	Milliseconds to wait after touch before capturing screenshot (default: 350)
`device_id`	No	Device profile ID (defaults to active device)
`normalized`	No	Whether coordinates are normalized 0.0 to 1.0 (default: false)
`duration_ms`	No	Touch hold duration in milliseconds (default: 1000)
`capture_after`	No	Whether to capture a screenshot after holding (default: true)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden, and it only partially meets it. It conveys what a long press accomplishes in the UI, but never mentions that a screenshot is captured afterward by default (capture_after defaults true), what is returned, or that a long press can trigger destructive menu actions on the watch.

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?

A single front-loaded sentence with the action first and the motivating example second; there is no filler or redundancy. It is arguably too terse for a seven-parameter tool, but nothing in it is wasted.

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

Completeness3/5

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

For a seven-parameter interaction tool with no annotations and no output schema, the description covers the core action but omits what the caller gets back and the fact that a screenshot is taken by default. The rich schema mitigates this, but the missing return/effect disclosure leaves a real gap.

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 100%, so all seven parameters including duration_ms, wait_ms, capture_after, and normalized are already documented in the schema. The description adds no coordinate format, duration, or device-targeting guidance beyond that, so the baseline 3 applies.

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: 'Long-press at specific coordinates on the watch touchscreen.' The verb distinguishes it from tap_screen, swipe_screen, and press_button without needing to name them. It stops short of explicitly contrasting with those siblings, but the action is unambiguous.

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

Usage Guidelines3/5

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

The parenthetical '(e.g. to open a watchface complication or menu)' implies when to reach for a long press rather than a tap, which is useful context. However, it never names tap_screen as the alternative for short presses or states any precondition such as the target element being visible on screen.

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