Connect NativeBridge to ChatGPT: Run Android Sessions via MCP
Learn how to connect NativeBridge to ChatGPT using a managed MCP server. Execute Android sessions, manage APK uploads, and orchestrate device testing via AI.
If you need to connect NativeBridge to ChatGPT to orchestrate Android testing sessions, manage APK uploads, and monitor device fleets directly through a chat interface, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and NativeBridge's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses Claude, check out our guide on connecting NativeBridge to Claude or explore our broader architectural overview on connecting NativeBridge to AI Agents.
Giving a Large Language Model (LLM) read and write access to mobile testing infrastructure is an engineering challenge. You have to handle authentication lifecycles, map massive JSON schemas to MCP tool definitions, and deal with the asynchronous nature of hardware provisioning. Every time the upstream API changes, you have to update your server code, redeploy, and test the integration. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for NativeBridge, connect it natively to ChatGPT, and execute complex device testing workflows using natural language.
The Engineering Reality of the NativeBridge API
A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against a mobile device infrastructure API - or maintaining custom connectors for 100+ other platforms - is painful. You are not just managing simple database rows; you are orchestrating virtualized hardware, managing heavy binary uploads, and dealing with asynchronous provisioning states.
If you decide to build a custom MCP server for NativeBridge, you own the entire API lifecycle. Here are the specific integration challenges that break standard CRUD assumptions when working with this platform:
Handling Binary Uploads via LLMs
Language models output text. They cannot natively POST a 50MB Android App Bundle (AAB) or APK file directly through a JSON-RPC tool call. To deploy an application to NativeBridge via an LLM, your integration layer must support translating a public URL into a binary stream, or act as an intermediary that fetches the file and proxies the multipart form-data upload to the NativeBridge /applications endpoint. If your custom server demands a local file path, the LLM will fail to execute the tool.
Asynchronous Device Provisioning
Hardware takes time to boot. When you request a new Android device session via the NativeBridge API, the API immediately returns a session record and a "magic link", but the underlying emulator or physical device might still be spinning up. LLMs are notoriously bad at handling asynchronous state. If your MCP tools do not explicitly instruct the LLM on how to present this state to the user, the agent might hallucinate that the app is instantly running and ready for interaction, confusing the engineer relying on the output.
Hard Rate Limits on Polling
Because state is asynchronous, developers often write scripts that aggressively poll NativeBridge to check if an emulator is ready. This leads directly to rate limiting. It is critical to understand that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream NativeBridge API returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. Truto normalizes upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller - whether it is ChatGPT, a custom agent, or a workflow script - is entirely responsible for implementing retry and exponential backoff logic. Do not expect Truto to automatically retry or absorb rate limit errors.
Generating the NativeBridge MCP Server
Instead of building a translation layer from scratch, Truto dynamically generates an MCP server from your connected NativeBridge account. The server is completely documentation-driven - Truto parses the integration's schemas and dynamically exposes compliant tools over a JSON-RPC 2.0 endpoint.
You can generate the MCP server in two ways: via the Truto UI or programmatically via the API.
Method 1: Via the Truto UI
For most DevOps engineers and IT admins, generating the server via the dashboard is the fastest path.
- Log in to Truto and navigate to the Integrated Accounts page.
- Select your connected NativeBridge account.
- Click the MCP Servers tab.
- Click Create MCP Server.
- Select your desired configuration (e.g., restrict to specific tags or require an API token for extra security).
- Copy the generated MCP server URL (e.g.,
https://api.truto.one/mcp/a1b2c3d4e5f6...).
This URL contains a cryptographic token that securely maps to your specific integrated NativeBridge account.
Method 2: Via the Truto API
If you are building a platform that programmatically provisions AI tools for your own engineering team, you can generate the MCP server via a REST API call.
Make a POST request to /integrated-account/:id/mcp with your desired configuration:
curl -X POST https://api.truto.one/integrated-account/YOUR_ACCOUNT_ID/mcp \
-H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Android QA Agent Server",
"config": {
"methods": ["read", "write"],
"tags": ["devices", "sessions"]
}
}'The API validates that tools exist, generates a secure token, provisions the edge infrastructure, and returns a ready-to-use URL:
{
"id": "mcp_8f7e6d5c",
"name": "Android QA Agent Server",
"config": {
"methods": ["read", "write"],
"tags": ["devices", "sessions"]
},
"expires_at": null,
"url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}Connecting the MCP Server to ChatGPT
Once you have your Truto MCP server URL, you need to connect it to your AI interface. You can do this natively in the ChatGPT UI, or via a manual configuration file if you are orchestrating agents locally or in CI/CD.
Method A: Via the ChatGPT UI
OpenAI has natively integrated MCP support for Plus, Pro, Enterprise, and Edu users.
- Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
- Toggle Developer mode to ON.
- Under MCP servers / Custom connectors, click Add new server.
- Name: NativeBridge (Truto)
- Server URL: Paste the Truto MCP URL you generated earlier.
- Click Save.
ChatGPT will perform a handshake (the initialize JSON-RPC method), discover all available NativeBridge tools, and make them available in your chat window.
Method B: Via Manual Config File (SSE Transport)
If you are running custom agents using LangChain, LangGraph, or desktop environments that rely on configuration files, you connect to the remote Truto URL using an SSE (Server-Sent Events) wrapper.
Create an mcp_config.json file (or append to your Claude Desktop config if using that as an agent runner) pointing to the official SSE proxy:
{
"mcpServers": {
"nativebridge_truto": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-sse",
"--url",
"https://api.truto.one/mcp/a1b2c3d4e5f6..."
]
}
}
}This configuration instructs your agent framework to launch the SSE transport client, which maintains a persistent connection to the Truto edge router to execute tool calls.
Hero Tools for NativeBridge
Truto dynamically generates specific tools mapped to NativeBridge's resources. Here are the highest-leverage tools your AI agent can now use to orchestrate mobile testing.
List All NativeBridge Devices
This tool retrieves the fleet of available emulators and physical devices in your NativeBridge account. It returns critical metadata like the OS version, model name, and whether the target is an emulator or real hardware.
Contextual usage: Agents should always call this before creating a session to ensure they target a valid, active deviceId.
"Get a list of all available Android emulators currently active in our NativeBridge account and table their OS versions."
Create a NativeBridge Application
This tool allows the agent to upload an Android application (APK or AAB) to NativeBridge from a public URL and generates a shareable magic link for testers.
Contextual usage: Pass the apkUrl parameter. If you supply both a file and a URL, the file takes precedence, but since LLMs operate in text, URLs are the required path for agentic uploads.
"Take this staging build URL (https://ci.company.com/builds/app-staging-v2.apk) and upload it to NativeBridge as a new application."
Create a NativeBridge Device Session
This is the core operational tool. It spins up a new Android device session, optionally launching a specific application if an appId is provided.
Contextual usage: The agent will receive a sessionId, a sessionUrl, and a magicLink. The agent must provide the magicLink to the human user so they can access the streaming emulator in their browser.
"Launch a new device session on the Pixel 7 emulator (ID: dev_8899) and install the application we just uploaded. Give me the magic link when it is ready."
Get Single NativeBridge Session by ID
Retrieves the current status and access details for an ongoing test session.
Contextual usage: Useful for auditing active sessions or retrieving a lost magic link for a QA engineer.
"Check the status of session ID sess_12345 and get the magic link for the tester."
Delete a NativeBridge Session by ID
Terminates an active session and frees up the underlying hardware resources.
Contextual usage: Crucial for cost control and cleanup. Instruct your agent to aggressively tear down sessions when testing is complete to avoid idle billing.
"Terminate the device session sess_12345 to free up the hardware resources."
List All NativeBridge Project Files
Queries the files and folders associated with a specific NativeBridge project environment.
Contextual usage: Useful when validating that test scripts, logs, or configuration files were properly seeded into a project environment before launching a test.
"List all the files currently stored in our Android Core QA project (ID: proj_abc)."
For the complete tool inventory, including project imports and application listing, visit the NativeBridge integration page.
Workflows in Action
Exposing individual endpoints is useful, but the real power of MCP is enabling an LLM to string these tools together into autonomous workflows. Here are two real-world scenarios showing exactly how ChatGPT orchestrates NativeBridge.
Scenario 1: Automated QA Deployment and Session Initialization
When a CI/CD pipeline finishes a build, a QA engineer needs that build running on a specific OS version for manual spot-checking. Instead of logging into a web portal, uploading a file, searching for a device, and waiting for a boot sequence, they just ask ChatGPT.
"Upload this staging APK (https://ci.company.com/builds/v2.1-rc.apk) to NativeBridge. Find an available Android 14 emulator, launch a session with this new app, and give me the magic link to start testing."
Tool execution sequence:
create_a_native_bridge_application: The agent passes theapkUrl. The NativeBridge API downloads the APK and returns anid(e.g.,app_999).list_all_native_bridge_devices: The agent requests the fleet data, filtering the JSON response in-memory to find an emulator whereosVersionis "14". It grabs theid(e.g.,dev_404).create_a_native_bridge_device_session: The agent calls this tool, passingdeviceId: "dev_404"andappId: "app_999".
Result: The agent responds: "I have uploaded v2.1-rc and provisioned a session on an Android 14 emulator. You can access your streaming test environment here: [Magic Link]."
sequenceDiagram participant User as User Prompt participant ChatGPT as ChatGPT participant TrutoMCP as Truto MCP Server participant NativeBridge as NativeBridge API User->>ChatGPT: "Upload APK and launch emulator." ChatGPT->>TrutoMCP: Call create_a_native_bridge_application(apkUrl) TrutoMCP->>NativeBridge: POST /applications NativeBridge-->>TrutoMCP: App ID and Details TrutoMCP-->>ChatGPT: Return App ID ChatGPT->>TrutoMCP: Call list_all_native_bridge_devices() TrutoMCP->>NativeBridge: GET /devices NativeBridge-->>TrutoMCP: Device List TrutoMCP-->>ChatGPT: Return Device IDs ChatGPT->>TrutoMCP: Call create_a_native_bridge_device_session(deviceId, appId) TrutoMCP->>NativeBridge: POST /sessions NativeBridge-->>TrutoMCP: Session ID and Magic Link TrutoMCP-->>ChatGPT: Return Magic Link ChatGPT-->>User: "Session ready. Here is your Magic Link."
Scenario 2: Infrastructure Cost Control and Cleanup
Idle emulators and orphaned sessions consume resources and drive up testing costs. An IT Admin can use ChatGPT to act as a garbage collector for development environments.
"Find the session for sess_8812. If it is active, terminate it to save resources."
Tool execution sequence:
get_single_native_bridge_session_by_id: The agent checks the state ofsess_8812.delete_a_native_bridge_session_by_id: Seeing that the session is still consuming compute, the agent executes the deletion tool.
Result: The agent responds: "Session sess_8812 was active. I have successfully deleted it and freed the associated resources."
Security and Access Control
Giving an AI agent control over your mobile testing infrastructure requires strict governance. Truto MCP servers provide hardware-level controls to ensure agents only access what they are explicitly authorized to touch.
- Method Filtering: Limit the server to safe operations. By passing
config: { methods: ["read"] }during creation, the agent can list devices and files but is cryptographically blocked from uploading apps or provisioning sessions. - Tag Filtering: Group tools by domain. You can restrict a specific MCP server to only tools tagged with
sessions, preventing the agent from interfering withprojectsor broader account settings. - Require API Token Auth: By default, anyone with the MCP URL can connect. For enterprise security, setting
require_api_token_auth: trueforces the client to pass a valid Truto session token, ensuring only authenticated engineers in your organization can execute tools. - Time-Bound Access (
expires_at): Generate ephemeral MCP URLs for temporary contractors or one-off CI/CD pipeline runs. Once the ISO timestamp is reached, the server automatically self-destructs at the edge.
Rethink Mobile QA with AI Agents
Connecting NativeBridge to ChatGPT fundamentally changes how engineering teams interact with mobile hardware. Instead of navigating complex UIs to upload binaries, search for device IDs, and manually string together test environments, you can instruct an agent to provision the exact state you need using natural language.
By leveraging Truto's managed MCP infrastructure, you bypass the pain of hand-coding JSON schemas, managing multipart uploads through an intermediary, and tracking OAuth token refreshes. You simply generate the secure URL, connect it to your LLM, and start testing.
FAQ
- Does Truto handle NativeBridge API rate limits automatically?
- No. Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream API returns HTTP 429, Truto passes that error to the caller and normalizes upstream rate limit info into standardized IETF headers. The calling agent is responsible for retry and backoff logic.
- How do I upload an Android app (APK) using an LLM?
- Because LLMs cannot send raw binary files, you use the NativeBridge tool to pass a public URL (apkUrl). The NativeBridge API fetches the file from the URL and registers it as a testable application.
- Can I restrict the AI agent from deleting active device sessions?
- Yes. When creating the Truto MCP server, you can apply method filtering (e.g., config: { methods: ['read'] }) to generate a read-only server that prevents the LLM from executing destructive actions.