---
title: "Connect NativeBridge to Claude: Manage cloud devices and projects"
slug: connect-nativebridge-to-claude-manage-cloud-devices-and-projects
date: 2026-07-16
author: Roopendra Talekar
categories: ["AI & Agents"]
excerpt: "Learn how to connect NativeBridge to Claude via a managed MCP server. Automate Android app deployments, test sessions, and cloud device orchestration using AI."
tldr: "Connecting NativeBridge to Claude requires an MCP server to translate LLM intents into REST APIs. This guide shows how to generate a Truto MCP server, configure Claude, and automate Android device provisioning and application testing."
canonical: https://truto.one/blog/connect-nativebridge-to-claude-manage-cloud-devices-and-projects/
---

# Connect NativeBridge to Claude: Manage cloud devices and projects


If you are orchestrating mobile application testing, managing Android emulator fleets, or automating application deployments, you need a way to integrate NativeBridge into your agentic workflows. To connect NativeBridge to Claude natively, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's JSON-RPC tool calls and NativeBridge's REST API. You can either [build and maintain this infrastructure yourself](https://truto.one/the-hands-on-guide-to-building-mcp-servers-for-ai-agents-2026/), or use a managed platform like Truto to dynamically generate a [secure, authenticated MCP server URL](https://truto.one/managed-mcp-for-claude-full-saas-api-access-without-security-headaches/). 

If your team uses ChatGPT, check out our guide on [connecting NativeBridge to ChatGPT](https://truto.one/connect-nativebridge-to-chatgpt-run-android-sessions-and-apps/) or explore our broader architectural overview on [connecting NativeBridge to AI Agents](https://truto.one/connect-nativebridge-to-ai-agents-orchestrate-mobile-app-testing/).

Giving a Large Language Model (LLM) read and write access to your cloud device infrastructure is a complex engineering challenge. You must handle authentication boundaries, normalize complex multipart payloads for app uploads, and map nested device configurations to flattened MCP tool schemas. Every time the API changes, you have to update your server code, redeploy, and test. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for NativeBridge, connect it natively to Claude, and execute complex QA and DevOps 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 specialized infrastructure platforms like NativeBridge requires deep domain handling.

If you decide to [build a custom MCP server](https://truto.one/the-hands-on-guide-to-building-mcp-servers-for-ai-agents-2026/) for NativeBridge, you own the entire integration lifecycle. Here are the specific challenges you will face:

**Application Artifact Ingestion**
NativeBridge requires deploying applications (APKs or AABs) before they can be assigned to a device session. This is not a simple JSON payload. You must build your server to gracefully handle the precedence of URL-based application ingest vs. direct file ingestion. You must instruct the LLM on exactly which parameters take precedence. Truto abstracts this by mapping the underlying integration documentation directly to the tool's JSON Schema, ensuring Claude knows that providing `apkUrl` supersedes raw file buffers, preventing hallucinated or conflicting payloads.

**Asynchronous Session State Management**
Orchestrating cloud devices is inherently asynchronous. When you request a new NativeBridge device session, the infrastructure takes time to provision the emulator, load the OS version, and install the specified application. If you expose raw endpoints to Claude, the model may assume the session is immediately interactive. You must design your tool definitions to instruct the LLM to poll the session state using the `id` returned from the creation command. 

**Flat Namespace Collision Resolution**
MCP clients pass all arguments to tools in a single flat JSON object. However, NativeBridge APIs often separate URL path parameters, query parameters, and HTTP body configurations. Truto's MCP router dynamically splits Claude's flat argument dictionary into the correct query and body schemas behind the scenes. If a query parameter and body parameter share a name, the query schema safely takes precedence—all without writing custom routing logic.

## How to Generate a NativeBridge MCP Server

Rather than hand-coding tool definitions, Truto derives them dynamically from the NativeBridge integration's underlying resource definitions and documentation schemas. You can generate an MCP server via the Truto UI or programmatically via the API.

### Method 1: Via the Truto UI

For ad-hoc agent testing or manual configuration, the UI is the fastest path:

1. Navigate to the **Integrated Accounts** page in your Truto dashboard and select your connected NativeBridge instance.
2. Click the **MCP Servers** tab.
3. Click **Create MCP Server**.
4. Configure the server (e.g., name it "NativeBridge DevOps", select allowed methods like `read` or `write`, and set an optional expiration date).
5. Copy the generated MCP server URL (e.g., `https://api.truto.one/mcp/a1b2c3d4e5f6...`).

### Method 2: Via the Truto API

For platform engineers building [multi-tenant AI products](https://truto.one/how-to-generate-mcp-servers-for-your-saas-users-2026-architecture-guide/), you can generate MCP servers programmatically. This endpoint validates that the NativeBridge integration is "AI-ready" (has documented endpoints) and stores the hashed token securely in a distributed Key-Value store.

```bash
curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "NativeBridge CI/CD Agent",
    "config": {
      "methods": ["read", "write", "custom"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'
```

The response contains the exact URL Claude needs to connect:

```json
{
  "id": "mcp-789",
  "name": "NativeBridge CI/CD Agent",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}
```

## Connecting the MCP Server to Claude

Once you have your NativeBridge MCP server URL, you must register it with your local Claude Desktop environment. 

### Method A: Via the Claude UI

The simplest way to add the connector is through the application settings:

1. Open Claude Desktop.
2. Navigate to **Settings → Integrations** (or **Connectors** depending on your version).
3. Click **Add MCP Server**.
4. Name the server (e.g., "NativeBridge Orchestrator") and paste the Truto MCP URL.
5. Click **Add**. Claude will instantly execute the JSON-RPC `initialize` handshake and load the NativeBridge toolset.

### Method B: Via the Config File

For automated deployments or developer environments, you can manually update Claude's JSON configuration file. By default, Claude's config file lives at:
- macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
- Windows: `%APPDATA%\Claude\claude_desktop_config.json`

Add the NativeBridge URL under the `mcpServers` object. Because Truto MCP servers operate over standard HTTP POST endpoints, you can use the official `@modelcontextprotocol/server-sse` proxy if your environment requires standardizing transport, or use a bridge script to handle the remote connection.

```json
{
  "mcpServers": {
    "nativebridge": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f67890"
      ]
    }
  }
}
```

Restart Claude Desktop. The NativeBridge tools will now be available in your chat context.

## Hero Tools for NativeBridge

Truto dynamically translates NativeBridge API resources into flattened, snake_case MCP tools. Here are the most critical operations you can execute with your newly connected agent.

### List Devices
**Tool:** `list_all_native_bridge_devices`
Returns the active catalog of Android devices and emulators available in your environment, including their `osVersion`, `modelName`, and `isEmulator` flags. 

> "Claude, list all available physical devices and emulators in NativeBridge. Filter out anything running Android 10 or older."

### Upload Applications
**Tool:** `create_a_native_bridge_application`
Ingests an Android APK or AAB into the NativeBridge ecosystem. If you pass an `apkUrl`, NativeBridge pulls the artifact securely. Returns the application record including its `magicLink` and unique identifier.

> "Upload the latest staging build using the provided AWS S3 presigned URL to NativeBridge. Return the application ID so we can launch it."

### Launch Device Sessions
**Tool:** `create_a_native_bridge_device_session`
Provisions a cloud device and optionally side-loads a specific application. This is the core orchestrator tool for QA automation.

> "Create a new device session using the Pixel 7 emulator (Device ID: emu-px7-01). Deploy the staging app we just uploaded (App ID: app-998) onto the device. Output the sessionUrl for the testing team."

### Inspect Session State
**Tool:** `get_single_native_bridge_session_by_id`
Retrieves the real-time configuration and status of an active device session.

> "Check the status of session ID sess-456. Confirm if the application successfully launched and whether the device is ready for interaction."

### Manage Projects
**Tool:** `list_all_native_bridge_projects`
Lists logical groupings of applications, files, and configurations within NativeBridge. Useful for maintaining clean environments across different engineering squads.

> "Show me all active NativeBridge projects. Are there any projects missing recent application uploads?"

### Terminate Sessions
**Tool:** `delete_a_native_bridge_session_by_id`
Cleans up expensive cloud infrastructure by terminating unneeded device sessions. 

> "The automated test suite is complete. Terminate session ID sess-456 immediately to free up cloud resources."

For the complete inventory of available NativeBridge operations, query parameters, and schema details, visit the [NativeBridge integration page](https://truto.one/integrations/detail/nativebridge).

## Workflows in Action

Connecting tools is only the first step. The real value of an MCP server is enabling Claude to autonomously sequence complex, multi-step cloud infrastructure workflows.

### Scenario 1: Automated QA Provisioning

Mobile QA engineers waste hours manually downloading APKs, booting local emulators, and verifying logs. You can instruct Claude to handle the entire deployment lifecycle.

> "We just cut a release candidate. Upload the APK from this URL `https://ci.internal.com/build-88.apk` to NativeBridge. Once it's uploaded, find an available Android 13 emulator and launch a session with that application. Give me the shareable session URL when it's ready."

**How the agent executes this:**
1. **`create_a_native_bridge_application`**: Claude submits the URL payload to NativeBridge. The API responds with an `id` representing the uploaded artifact.
2. **`list_all_native_bridge_devices`**: Claude searches the device catalog and filters the response array to locate an emulator where `osVersion` is 13.
3. **`create_a_native_bridge_device_session`**: Claude takes the device ID and the application ID, passing them into the session creation endpoint. It extracts the `sessionUrl` from the result and formats it for the engineer.

```mermaid
sequenceDiagram
    participant User as QA Engineer
    participant Claude as Claude Desktop
    participant MCP as Truto MCP Server
    participant API as NativeBridge API
    
    User->>Claude: "Upload build-88.apk and<br>launch on Android 13"
    Claude->>MCP: Call create_a_native_bridge_application
    MCP->>API: POST /v1/applications
    API-->>MCP: Returns App ID (app-123)
    MCP-->>Claude: Tool result
    Claude->>MCP: Call list_all_native_bridge_devices
    MCP->>API: GET /v1/devices
    API-->>MCP: Returns device list
    MCP-->>Claude: Tool result
    Claude->>MCP: Call create_a_native_bridge_device_session
    MCP->>API: POST /v1/sessions
    API-->>MCP: Returns sessionUrl
    MCP-->>Claude: Tool result
    Claude-->>User: "Session ready. Access here: [URL]"
```

### Scenario 2: Infrastructure Cleanup and Auditing

Orphaned cloud emulators incur significant costs. An IT Administrator can use Claude to audit and clean up stale environments.

> "Audit my NativeBridge account. List all current projects and check if any have lingering active sessions. If you find any sessions older than 24 hours, terminate them and give me a summary of what was deleted."

**How the agent executes this:**
1. **`list_all_native_bridge_projects`**: Claude maps out the workspace hierarchy.
2. **`get_single_native_bridge_session_by_id`** (looped): Based on context, Claude checks the state of flagged sessions to verify timestamps.
3. **`delete_a_native_bridge_session_by_id`**: For any session meeting the stale criteria, Claude executes the delete operation. 
4. Claude synthesizes the deleted IDs into an executive summary for the administrator.

## Rate Limits and API Exhaustion

### Truto's Passthrough Approach
NativeBridge infrastructure operations are expensive, and their API enforces strict rate limits to prevent abuse. **Truto does not retry, throttle, or apply automatic backoff on rate limit errors.** 

When the NativeBridge API returns an HTTP 429 (Too Many Requests), Truto passes that exact error directly back to the calling MCP client. 

However, Truto *does* normalize the upstream rate limit information into standardized HTTP headers per the IETF specification. Regardless of NativeBridge's internal header naming conventions, Truto ensures the MCP response contains `ratelimit-limit`, `ratelimit-remaining`, and `ratelimit-reset`. 

Your agent architecture (whether that is Claude Desktop natively, or a LangGraph orchestrator) is strictly responsible for reading the `ratelimit-reset` window and implementing its own retry loops and exponential backoff. This ensures your LLM context retains full control over execution timing rather than hanging indefinitely inside the integration proxy layer.

## Security and Access Control

Exposing cloud infrastructure management tools to an LLM requires strict governance. Truto MCP servers utilize multiple security constraints at the token configuration level:

* **Method Filtering (`config.methods`)**: Restrict servers to specific operation categories. If you only want Claude to audit devices, you can set `methods: ["read"]`. Attempting a `create` or `delete` tool will instantly fail. 
* **Tag Filtering (`config.tags`)**: Bind the MCP server to specific functional domains (e.g., only exposing resources tagged as `applications` but hiding `sessions`).
* **Dual Authentication (`require_api_token_auth`)**: By default, possessing the MCP URL grants access. By enabling this flag, clients must *also* pass a valid Truto API Bearer token in the `Authorization` header, preventing unauthorized usage if a URL leaks in logs.
* **Time-to-Live (`expires_at`)**: Ideal for temporary contracting work or isolated CI/CD runs. Generate an MCP server that self-destructs after a specific ISO datetime.

## Moving Past Manual Infrastructure Workflows

Connecting NativeBridge to Claude fundamentally changes how mobile engineering teams interact with cloud device infrastructure. Instead of juggling curl scripts, navigating complex dashboards, and manually uploading massive APKs, engineers can orchestrate the entire QA lifecycle conversationally. 

By leveraging Truto's dynamic MCP server generation, you avoid the heavy lifting of maintaining JSON schemas, resolving multipart artifact uploads, and handling OAuth token refreshes. Your agent orchestrates the cloud—Truto handles the API translation layer.

> Stop spending engineering cycles building and maintaining custom MCP servers for proprietary vendor APIs. Let Truto generate secure, AI-ready integration endpoints for your entire tech stack.
>
> [Talk to us](https://cal.com/truto/partner-with-truto)