Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_set_location

Idempotent

Simulate GPS coordinates on an iPhone to test location-aware apps, then clear the simulation to restore the real location.

Instructions

Simulate GPS for testing location-aware apps. Supply both lat (-90–90) and lon (-180–180), in finite decimal degrees, or clear=true without coordinates to restore real location; combining clear with coordinates is refused. Every app sees the simulated position until cleared; it is not a navigation or address lookup tool. Counts as one daemon action and requires authorized device control. Returns the applied location/clear status; on a transport failure the effect is unknown. Inspect the result before proceeding and clear the simulation when the test ends.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude in decimal degrees (WGS84), -90..90.
lonNoLongitude in decimal degrees (WGS84), -180..180.
clearNo`true` (without lat/lon) returns the phone to its real location.
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. 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"
+}
  2. First observedv0.21.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond annotations, the description discloses that the simulated location affects every app until cleared, that the call counts as one daemon action, that authorized device control is required, and that a transport failure leaves the effect unknown. It also advises inspecting the result and cleaning up the simulation, which is exactly the behavioral context an agent needs.

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 front-loaded with the purpose, then gives invocation rules, side effects, failure behavior, and cleanup guidance. Every sentence contributes useful information, and there is no redundant or filler text.

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?

Although there is no output schema, the description states that it returns the applied location or clear status and notes the uncertainty on transport failure. Together with the annotations and fully described schema, this is complete enough for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents the parameters, but the description adds meaningful semantics: lat and lon must be supplied together, clear=true must be used without coordinates, and combining clear with coordinates is refused. It does not add detail about the instance parameter, but the schema covers that adequately.

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 uses a specific verb and resource: simulate GPS for testing location-aware apps. It also explicitly says the tool is not a navigation or address lookup tool, which helps an agent distinguish it from conceptually adjacent requests. The scope is clear without needing to inspect the schema.

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?

It states the primary use case, the two valid invocation modes (lat/lon together or clear=true alone), the refusal of mixed clear and coordinates, and the need to clear the simulation when testing ends. These are explicit when, when-not, and cleanup instructions.

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