Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_apps

Read-only

Find an app's bundle ID by name instead of guessing. Searches installed apps, a bundled catalog, then the App Store, and returns candidates with bundle IDs and match details.

Instructions

Find an app's bundle id by name instead of guessing it. Read-only: it never touches the screen and takes no owner lease. Searches the phone's own app list, then a bundled catalog of popular apps (bundle ids verified against Apple's lookup API, plus Apple's built-in apps), then the App Store only when neither matched. Exact name/alias matches hide partial ones. Each candidate carries name, bundle_id, source (installed|catalog|apple), installed_verified, and publisher when known; installed_verified=false with installation_checked=false means unknown, not absent. Pick the candidate whose name and publisher fit, then launch it with launch_app bundle — or give launch_app app the exact name and let the daemon resolve it (it refuses ambiguous names with candidates instead of guessing).

Input Schema

NameRequiredDescriptionDefault
limitNo1–30 candidates. Default 10.
queryYesThe app's name as a person would say it (微信, WeChat, 招商银行, Settings) or a bundle id. 1–100 characters.
sourceNo`auto` (default: the phone's own app list, then the bundled catalog, then the App Store), `installed`, `catalog` (offline), or `apple`.
countryNoApp Store storefront for the store search, two letters. Default: the store the phone's apps came from (or IPHONE_USE_STORE_COUNTRY, else the Region setting); `cn` only when none is known, with a warning. The answer's `country_source` says which.
instanceNoInstalled local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.27.34
    • changedInput schema / properties / country / description
      Previous value: -"App Store storefront for the store search, two letters. Default `cn`."New value: +"App Store storefront for the store search, two letters. Default: the\nstore the phone's apps came from (or IPHONE_USE_STORE_COUNTRY, else the\nRegion setting); `cn` only when none is known, with a warning. The\nanswer's `country_source` says which."
    • addedInput schema / properties / limit / minimum
      Added value: +0
  2. Changed1 schema field changedv0.27.3
    • addedInput schema / properties / instance
      Added value: +{
+  "description": "Installed local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.",
+  "type": "string"
+}
  3. First observedv0.21.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations: no screen interaction, no owner lease, ordered source fallback with App Store last, exact matches suppressing partials, and the important caveat that installed_verified=false with installation_checked=false means unknown rather than absent. It also discloses the ambiguity-refusal behavior instead of guessing.

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?

Purpose and safety statement are front-loaded, and the candidate-field/next-step guidance follows logically. It is dense — long semicolon-linked clauses in the final sentence — but nearly every clause carries decision-relevant information.

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?

For a 5-parameter, read-only lookup with no output schema, the description covers what each candidate field means, what the edge-case flags imply, and how to act on results. There is no output schema gap left unaddressed and no missing prerequisite.

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 query/limit/source/country/instance are already documented at the parameter level. The description reinforces `source` ordering semantics and the name-vs-bundle-id form of `query`, but adds little about limit, country, or instance. Baseline 3 is right when the schema carries the detail.

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?

Opens with a specific verb+resource+goal: "Find an app's bundle id by name instead of guessing it." That immediately separates it from phone_install_app (which installs) and from launch tools, so an agent can pick it without reading schemas.

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?

States the exact search cascade (phone list -> bundled catalog -> App Store) and what selects each stage via `source`. It also names the follow-on alternatives explicitly: pass a bundle id to launch_app, or hand launch_app the exact name and let the daemon refuse ambiguity rather than guess.

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