Skip to main content
Glama
Sign In
Karagöz

Karagöz

by yagizdo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Install karagoz's iPhone runner

install_runner

Builds the Karagöz runner for a paired iPhone over USB and installs it, enabling UI tree, tap, swipe, text, and key automation on iOS.

Instructions

Build karagoz's runner with your Apple team and install it on a paired iPhone over USB; ui_tree, tap, swipe, text and key need it there.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "install_runner"
  }
}

Input Schema

NameRequiredDescriptionDefault
teamNoApple team ID; needed only when Xcode lists several.
deviceNoId or name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

The annotations already establish that this is a non-destructive mutating operation with open-world characteristics. The description adds useful behavioral context beyond annotations: it builds via an Apple team and installs over USB to a paired iPhone, and it explains downstream tool dependency. It does not mention idempotency, replacement behavior, or provisioning side effects.

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 definition is a single front-loaded sentence with no wasted wording. It packs the action, environment, and dependency information efficiently.

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

Completeness4/5

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

For a build-and-install operation with an output schema absent, the description covers the key prerequisites, environment, and dependency on UI automation tools. It leaves out secondary details such as expected duration or whether an existing runner is replaced, but the core call context is present.

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 the team and device parameters are already fully documented. The description mentions Apple team and paired iPhone in natural language, but does not add syntax, format, or selection guidance beyond the schema.

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?

The description uses specific verbs and resource: it builds and installs karagoz's runner on a paired iPhone over USB. It clearly identifies the runner as distinct from generic app installation, though it does not explicitly name the sibling tool install or state how it differs from uninstall_runner.

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

Usage Guidelines4/5

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

It gives clear usage context by stating that ui_tree, tap, swipe, text, and key need the runner installed. It does not explicitly state when not to use it or name an alternative tool, but the operational context is clear.

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

Deploy Server

Other Tools