Skip to main content
Glama
appium

MCP Appium

Official
by appium
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

appium_geolocation

Get, set, or reset device geolocation on iOS and Android to test location-based app behavior.

Instructions

Get, set, or reset the device geolocation (GPS coordinates). Works on both iOS (simulators and real devices) and Android (emulators and real devices with mock location enabled). Use action=get to read current coordinates, action=set with latitude/longitude (and optional altitude for Android) to simulate a location, or action=reset to restore the system default. Note: On Android emulators, reset is not supported — use action=set to manually restore coordinates instead. On Android real devices, the mocked location may persist until the GPS cache refreshes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform. get: read the current device geolocation. set: set the device geolocation (requires latitude and longitude; optional altitude for Android). reset: reset the geolocation to the default/system value. Not supported on Android emulators — use action=set instead.
altitudeNoAltitude value in meters. Android only, defaults to 0. Ignored on iOS. Used with: set.
latitudeNoLatitude value (-90 to 90). Measurement of distance north or south of the Equator. Required for: set.
longitudeNoLongitude value (-180 to 180). Measurement of distance east or west of the prime meridian. Required for: set.
sessionIdNoSession ID; defaults to the active session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.95.0
    • changedInput schema / properties / sessionId / description
      Previous value: -"Session ID to target. If omitted, uses the active session."New value: +"Session ID; defaults to the active session."
  2. First observedv1.92.11

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the minimal annotations, the description discloses meaningful behavioral caveats: Android emulator reset is unsupported, mocked locations may persist until GPS cache refresh on Android real devices, and altitude is Android-only. These details help an agent anticipate platform-specific outcomes. The readOnlyHint=false annotation is consistent with the mutating set/reset actions.

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 compact and front-loaded, starting with the core function and platform scope before detailing action modes and edge cases. Every sentence contributes operational information, and there is no filler or redundant restatement.

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?

The description fully covers action selection, platform constraints, required parameters, and important caveats. There is no output schema, and the description does not specify the exact return shape of action=get, but the invocation path is otherwise complete and unambiguous.

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 baseline is 3. The description adds value by explaining action semantics and platform dependencies, such as action=set requiring latitude/longitude, altitude being Android-only, and reset having an Android emulator limitation. This supplements the schema rather than merely repeating it.

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 opens with 'Get, set, or reset the device geolocation (GPS coordinates)', providing specific verbs and the resource being operated on. It clearly distinguishes this tool from sibling Appium tools by naming the exact geolocation capability and supported platforms.

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?

The description gives explicit action-based guidance: use action=get to read, action=set with latitude/longitude to simulate, and action=reset to restore defaults. It also notes that reset is unsupported on Android emulators and directs users to action=set instead. It does not mention alternative sibling tools, but it clearly scopes its own usage context.

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