Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the MobileBoost API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fmobileboost.io%2Fmobileboost" | shStep 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fmobileboost.io%2Fmobileboost" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with MobileBoost API.
Create a mobile test case from natural-language commands with tags, inputs, and setup and teardown requests
Generate and verify automation code for a test across a configurable number of verificationRounds
Upload an Android .apk or iOS .ipa or simulator build for testing
Execute tests by testIds or tags on an emulator, simulator, or reserved physical device
GET STARTED
Poll a run by runId until it reports succeeded, failed, and blocked tests
Organise the test library into nested folders and move tests between them
Stream organisation audit log events by cursor for SIEM ingestion
Patterns agents use MobileBoost API for, with concrete tasks.
★ Agent-Driven Mobile QA Through Jentic
A coding agent that has just changed a mobile app writes the matching test case as natural-language commands, asks MobileBoost to generate its automation, and runs it against the new build. Through Jentic the agent finds the create-test, generate, and execute operations by intent and follows the run by runId with a stored token, so test coverage keeps pace with code changes.
Create a test titled 'Login with valid credentials' with commands ['Open the app', 'Tap Sign in', 'Enter the test user email and password', 'Verify the home screen appears'], then poll GET /tests until its automation is generated
CI Test Runs on Every Build
A CI pipeline uploads each new .apk or .ipa with organisation_key and platform, then executes the regression suite by tag against the returned buildId, labelling the run with a trigger such as ci. The pipeline polls the run status until it is completed or cancelled and fails the build when failedTests is not empty.
Execute tests tagged 'regression' for organisationId 'org_123' against buildId 'b_456' with trigger 'ci', then poll GET /runs/{runId} until status is completed
Testing Against Staging Behind a Tunnel
Teams whose app talks to internal hosts start a MobileBoost Local tunnel and pass its tunnelName on execution, plus run variables such as the staging backend a canary test signs in against. Tests can run on a reserved physical handset with usePhysicalDevice for hardware-dependent flows.
Execute test IDs ['t_1', 't_2'] on a physical device with tunnelName 'staging' and variables {"API_BASE": "https://staging.internal"}
Audit and Usage Reporting
Security and platform teams poll the audit log with since set to the previous next_cursor and filter by event_type such as test.updated to feed Splunk or another SIEM, and review how many AI steps SDK sessions used per test over the last 1 to 90 days.
Retrieve audit log events with event_type 'test.updated' from 2026-11-01T00:00:00Z and return the next_cursor
17 endpoints — the mobileboost api runs ai-written end-to-end tests for ios and android apps: you describe a test case in natural-language commands, and mobileboost explores the app on a device, writes the automation code, verifies it over several passing runs, and commits it to your organisation's test repository.
METHOD
PATH
DESCRIPTION
/tests
Create a test case
/tests
Get tests
/tests/generate
Generate test automation
/tests/execute
Execute tests
/uploadBuild
Upload a build
/runs/{runId}
Get run status
/audit/logs
List audit logs
/tests
Create a test case
/tests
Get tests
/tests/generate
Generate test automation
/tests/execute
Execute tests
/uploadBuild
Upload a build
/runs/{runId}
Get run status
/audit/logs
List audit logs
What agents get from Jentic-routed access to this vendor.
Setup
Wiring MobileBoost by hand means setting the Bearer header, sending multipart build uploads with your organisation_key, and writing the loop that polls a run until it completes. Through Jentic you install once, import MobileBoost from the API Directory, store the token once, and your agent calls it.
Permission scoping
MobileBoost carries test and folder ids in the request body for most writes, so rules bound which operations your agent may call rather than which tests it touches. You choose the operations it may call, so destructive ones like deleting tests, folders, or uploaded builds are not included unless you add them.
Credential isolation
Your MobileBoost token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'run mobile app tests' or 'upload an app build', and Jentic returns the matching MobileBoost operation with its input schema so the agent calls the right endpoint without reading the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using MobileBoost API through Jentic.
What authentication does the MobileBoost API use?
The MobileBoost API authenticates with a Bearer token in the Authorization header per its OpenAPI spec, declared globally for every operation. The build upload also takes your organisation_key as a form field, and execute and generate calls name your organisationId in the body. Through Jentic the token is stored once, encrypted, by your own Jentic One instance and injected at call time.
Can MobileBoost write the test code for me?
Yes. Create a test with natural-language commands and leave autoGenerate on, or call the generate operation with testIds. MobileBoost explores the app on a device, writes the automation, and commits it only after it passes the number of consecutive runs set by verificationRounds, which defaults to 3.
Can I limit what my agent is allowed to do with the MobileBoost API?
Yes. For example, write a rule that allows only the get-tests, execute, and run-status operations, so the agent can launch existing tests and read their results while test deletion, build deletion, and the audit log stay out of reach, and every call it makes is logged.
What are the rate limits for the MobileBoost API?
The OpenAPI spec does not specify rate limits. Check the MobileBoost documentation at https://docs.mobileboost.io for current limits before polling run status at high frequency.
How do I run MobileBoost tests through Jentic?
Search Jentic for the intent 'run mobile app tests', which returns the MobileBoost execute operation on /tests/execute with its input schema; the agent sends organisationId, a buildId, and testIds or tags, then polls /runs/{runId} with the returned runId. To run it on your own infrastructure, install Jentic One from its GitHub repo.
Is there a MobileBoost MCP server?
You don't need an MCP server to give your agent the MobileBoost API. Jentic connects it directly from the API Directory: import it, store your token once, and your agent calls the test, build, and run operations. Operations are discovered on demand, so no extra tool definitions are loaded into the agent's context.
For Agents
Create natural-language mobile app tests, have MobileBoost generate and verify their automation, upload iOS and Android builds, run tests on devices, and poll run results. Authenticated with a Bearer token.
Use for: I need to add a login test for my Android app in plain English, Upload the latest iOS build and run the smoke tests against it, Run every test tagged checkout on a physical device, Check whether the nightly run has finished and which tests failed
Not supported: Does not handle app store publishing, crash reporting, or web browser testing. Use for AI-generated end-to-end testing of iOS and Android apps only.
The MobileBoost API runs AI-written end-to-end tests for iOS and Android apps: you describe a test case in natural-language commands, and MobileBoost explores the app on a device, writes the automation code, verifies it over several passing runs, and commits it to your organisation's test repository. You upload .apk, .ipa, or simulator builds, execute tests by ID or tag on emulators, simulators, or reserved physical handsets, and poll each run for succeeded, failed, and blocked tests. Folder operations organise the test library, and the audit log and SDK session usage endpoints feed SIEM tools and usage reporting.
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>