Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JevSim in the Settings app, open General, scroll to About, and confirm the version"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Complete a mobile UI sequence in one agent tool call.
JevSim is a local MCP server for agents working with iOS and Android apps. Give it a short plan—navigate, enter text, save, verify—and it executes the steps without returning to your main reasoning loop after every interaction. Jev, a text-based selection model, matches descriptions to current accessibility controls. XcodeBuildMCP (iOS) or Appium/UIAutomator2 (Android) performs the actions and checks the results.
If you are a human, give your agent this repository URL and ask: “Install JevSim for my iOS/Android project, connect it to your MCP tools, and verify the setup.” The instructions below are for that agent.
We reran the same ten-tap iOS Settings tour with the same checks after every action: open five sections and return from each. Pure agent means the main agent reads each screen and chooses the next control through XcodeBuildMCP. Agent + JevSim means it delegates the full route in one jevsim_run_steps call, with Jev selecting all ten targets.
Approach | Median execution time | Verified runs | Speedup |
Pure agent + XcodeBuildMCP | 117.3 s | 3/3 | 1× |
Agent + JevSim + XcodeBuildMCP | 35.7 s | 3/3 | 3.3× |
Measured September 21, 2026: GPT-6-astra (high reasoning) in Codex, Jev 1.13.0, XcodeBuildMCP 2.7.0, iPhone 17e / iOS 26.5 Simulator. Times include observations, target decisions, actions, checks, and intermediate agent/tool round trips; setup and initial route planning are excluded. This is one navigation benchmark with three runs per approach, not a general debugging or Android speed guarantee. Run details and reproduction.
Related MCP server: Mobile Testing AI Agent MCP Server
Inspect the environment. Use Node.js 24 and npm. Choose the platform from the user's project; install only that backend. Reuse existing tools and credentials where available.
Use the npm package. Configure the MCP client to run npx -y --package=@huaaudio/jevsim@0.1.0 jevsim. This downloads the compiled package; no clone or build is needed. Use an absolute path to Node.js 24’s npx if the client has a restricted PATH. Source installation remains available for development.
Prepare the backend. For iOS, use macOS, Xcode, and a booted simulator; JevSim starts its own pinned XcodeBuildMCP process. For Android, prepare ADB and a device/emulator, then start local Appium with UIAutomator2 using the Android instructions. Build, install, and launch the user's app with your existing tools.
Configure Jev. Supply TYPESAFE_API_KEY through your client's secret/environment configuration. The npm launcher does not automatically read .env; use the env-file launch option if needed. Preserve an existing .env; use .env.example only as a template. Never print or commit the key. Exact-identifier workflows also work without a key.
Register and verify the MCP server. Follow the agent installation runbook for absolute launch paths, client configuration, and readiness checks. Preserve other MCP servers. Installation is complete when you can discover all three tools, connect to the chosen backend, and inspect the intended device. Report any missing prerequisite precisely.
Tool | Use it to |
| Check backend connectivity, credential presence, and device inventory |
| Read the current accessibility state of one explicit device |
| Execute 1–10 supplied steps within 60 seconds; receive outcomes, timings, and any stop reason |
Call status and inspect first. For iOS, pass the observed simulatorId; for Android, pass platform: "android" and the ADB deviceId. Derive the plan from the app and the user's task. Every step must include a backend-verifiable expect condition.
For example, this is one step only if your app exposes the stated destination identifier:
{
"action": "tap",
"target": { "description": "Open the profile editor" },
"expect": { "predicate": "exists", "identifier": "profile.name" }
}Use a unique observed target.identifier when available; it skips the model request. Otherwise, Jev selects among current action-compatible controls or abstains. It cannot invent steps or generate typing text. Supported actions are tap, type, scroll, wait, and assert. See the request schema and complete example.
Reserve the device until the call returns. A completed result means every supplied expectation matched. If execution stops, inspect completedSteps, reason, and actionStatus, then inspect the app and re-plan. Never blindly replay a workflow or an uncertain action. See agent usage and recovery.
Delegate known sequences: reproduce a bug, navigate to a screen, exercise a form, or verify a change. Keep builds, code edits, visual interpretation, and decisions that depend on new information in your main agent. Split longer work into bounded sequences.
Supported: iOS Simulator and native Android accessibility. Android has been live-tested on an Android 15 emulator on macOS; physical Android devices and Windows/Linux hosts remain unvalidated.
Input: Android supports Unicode and empty replacement. The tested iOS backend accepts nonempty printable ASCII only.
Limits: inaccessible controls, Android WebViews, and arbitrary desktop GUIs need other tools. JevSim does not interpret screenshots.
Data: semantic selection sends accessibility text and field values to TypeSafe. Exact-identifier workflows skip those requests. Tool transcripts and backend logs may contain app data; see data handling.
Agent installation · Agent usage · Tools · Configuration · Troubleshooting · Release notes
Contributors: development guide for fixtures, tests, benchmark reproduction, and implementation history.
MIT. Independent project; automation backends and the TypeSafe service have their own terms and licenses.
Read accessibility state for an explicit booted iOS simulator or connected Android device. Use simulatorId for iOS; platform android and deviceId for Android. Android first use starts an Appium session. Returned UI text may be private.
| Name | Required | Description | Default |
|---|---|---|---|
| deviceId | No | ||
| platform | No | ios | |
| simulatorId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint: true. The description adds two non-obvious behavioral facts beyond that: Android first use starts an Appium session and returned UI text may be private. These are material for an agent deciding to call the tool and handling its output, and nothing contradicts the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences each carry distinct information: the operation, the parameter routing, and a side-effect/privacy warning. There is no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description covers purpose, parameter routing, a meaningful side effect, and a privacy caveat. It does not describe the return shape in detail or explicitly state that a device identifier is effectively required, but for a simple read tool the core context is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter-explanation burden. It successfully maps simulatorId to iOS and deviceId to Android, and clarifies that platform must be android for Android use. It could add a note about the platform default or what happens when no device identifier is supplied, but the core mapping is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise action and resource: 'Read accessibility state for an explicit booted iOS simulator or connected Android device.' This clearly distinguishes the tool from the siblings jevsim_status and jevsim_run_steps by framing it as an accessibility inspection rather than a status check or action execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit invocation guidance: use simulatorId for iOS, and platform android with deviceId for Android. It also warns that the first Android use starts an Appium session. It does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute up to 10 caller-planned tap/type/scroll/wait/assert steps within 60 seconds. Every action needs a deterministic expected outcome. Reserve the simulator or Android device for this call; do not use another UI tool concurrently. Returns partial progress and stops on ambiguity or failure. Never automatically replay uncertain actions.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | ||
| deviceId | No | ||
| platform | No | ios | |
| freshness | No | screen | |
| timeoutMs | No | ||
| simulatorId | No | ||
| minProbability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior, and the description adds valuable behavioral details: returns partial progress, stops on ambiguity or failure, and never automatically replays uncertain actions. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four terse, front-loaded sentences with no filler. Every sentence contributes operational value, and the most important usage constraints appear early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core execution behavior and safety constraints well, but with no output schema and no parameter-level descriptions, key details such as return format and the meaning of freshness or minProbability remain unclear. It is viable but not fully complete for such a complex nested schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only glosses over the steps array and the 60-second limit. It leaves deviceId, platform, freshness, minProbability, and the target/expect substructures largely unexplained, forcing the agent to infer meaning from names and enums alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear, specific action: execute up to 10 caller-planned tap/type/scroll/wait/assert steps. This is easily distinguishable from the sibling status/inspect tools, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete operational guidance: every step needs a deterministic expected outcome, the simulator or Android device must be reserved for this call, and no other UI tool should be used concurrently. It does not, however, explicitly compare against jevsim_status or jevsim_inspect for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check backend connection, supported capabilities, iOS simulators or Android devices, and credential presence. Defaults to iOS. No secrets returned.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | ios |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds valuable behavioral context: 'No secrets returned' and 'Defaults to iOS.' This goes beyond the annotation and reassures the agent about the tool's output and platform behavior. It does not cover every edge case, but for a status check that is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core purpose is front-loaded, followed by the platform default and a security-relevant note. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple one-optional-parameter tool with no output schema, the description covers the operation, the default, and a key output property ('No secrets returned'). It does not describe the return format, but for a status check with readOnlyHint this is a minor gap; sibling routing is also not addressed but is not essential here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the explanatory burden. It compensates by mapping the platform enum to 'iOS simulators or Android devices' and explicitly stating the default ('Defaults to iOS'). It does not name the parameter 'platform' directly, but the meaning is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and names concrete resources: backend connection, supported capabilities, iOS simulators/Android devices, and credential presence. It is clear what the tool does, though it does not explicitly contrast with siblings; the distinction is inferred from the word 'status' versus 'inspect' and 'run_steps'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a pre-flight or health-check usage, and 'Defaults to iOS' gives platform context. However, it does not state when to prefer this tool over jevsim_inspect or jevsim_run_steps, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0jevsim_inspectjevsim_run_stepsjevsim_statusScored across 3 tools
Each tool has a clearly distinct purpose: status checks environment and credentials, inspect reads the current UI state, and run_steps executes user-defined interaction steps. There is no meaningful overlap that would cause an agent to select the wrong tool.
All tools share the consistent jevsim_ prefix and use clear, readable snake_case names. The only minor deviation is jevsim_status being a noun rather than a verb_phrase like jevsim_inspect and jevsim_run_steps, but the pattern is still easy to predict.
Three tools is well-scoped for this server's apparent purpose: check environment, inspect UI state, and run UI interaction steps. Each tool earns its place and there is no redundancy or bloat.
The tool set covers the core workflow of connecting, inspecting, and interacting with a simulator or device in a structured way. Minor gaps exist—such as no explicit screenshot or app-launch tool—but agents can likely work around these using the provided inspect and run_steps capabilities.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Drive real Android & iOS devices and web browsers from natural language for mobile + web QA. 290+ tools across device control, app management, automation sessions, browser automation, and flow recording / replay. Bearer-auth — get a token at robotactions.com → Profile → API Tokens.
Melaya is a remote MCP server. It gives an assistant hands on your own Android phone and browser: it reads the screen through the accessibility tree, then taps, types and navigates inside the apps and sites you allow-list, with no per-app API. It also builds, schedules and runs agent pipelines across 6k+ connected tools. OAuth 2.1, nothing to install.
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
