@browserstack/mcp-server 2.3.0-beta.8 → 2.3.0-beta.9

package/capability/mobiledevicecontrol.capability-index.json

@@ -3,58 +3,48 @@
  "version": "1.0",
  "build_id": "6782f7e_2026-10-16T13:54:22Z",
  "mobiledevicecontrol": {
-  "summary": "Mobile device control: run a real Android or iOS device and drive the app on it step by step. The account side lists the devices this account can use, including private ones, uploads and lists app builds, reports parallel-session capacity, and keeps each session's record \u2014 status, shareable link and video \u2014 after the device is released. The session side starts a device with an installed build and drives it: find elements and read their text, position and attributes, tap them, type, swipe, screenshot, press keys, rotate, switch between the native app and a web view, move between the native app and a web view, and launch or close apps. Apps are RUN here \u2014 unlike Test Management, which authors cases, and Test Reporting, which records results pushed in from a runner. Browsers are not here \u2014 those are device control, which drives a page rather than an installed app \u2014 and neither is App Live: it has no API an agent can drive, so agent sessions run on App Automate and consume its minutes. A build must exist before a session starts and can only be uploaded from a public link, never a file on disk \u2014 so media for camera injection must come from elsewhere. The default Appium server is 1.x and rejects every `mobile:` command; ask for 2.19.0.",
+  "title": "Mobile Device Control (App Automate)",
+  "summary": "Mobile device control: run a real Android or iOS device and drive the app on it step by step. The account side lists the devices this account can use, including private ones, uploads and lists app builds, reports parallel-session capacity, and keeps each session's record \u2014 status, shareable link and video \u2014 after the device is released. The session side starts a device with an installed build and drives it: find elements and read their text, position and attributes, tap them, type, swipe, screenshot, press keys, rotate, switch between the native app and a web view, move between the native app and a web view, and launch or close apps. Apps are RUN here \u2014 unlike Test Management, which authors cases, and Test Reporting, which records results pushed in from a runner. Browsers are not here \u2014 those are device control, which drives a page rather than an installed app \u2014 and neither is App Live: it has no API an agent can drive, so agent sessions run on App Automate and consume its minutes. A build must exist before a session starts; it is uploaded here from a public link, or from a file on the user's own machine when the server runs there. App Live keeps a separate store, so an app uploaded for manual App Live testing is not available to sessions here. Media for camera injection must come from elsewhere. The default Appium server is 1.x and rejects every `mobile:` command; ask for 2.19.0.",
   "routing_terms": [
    "app automate",
+   "app build",
+   "app for automation",
    "appium",
    "appium session",
-   "webdriver",
-   "real device",
-   "mobile app",
-   "drive the app",
-   "tap",
-   "swipe",
-   "scroll",
-   "ui tree",
-   "page source",
+   "close app",
+   "device control",
    "device list",
-   "upload app",
-   "app build",
+   "device property",
+   "drive a device",
+   "drive the app",
+   "foreground app",
+   "getprop",
+   "hardware button",
+   "home button",
+   "keyboard",
+   "keyboard open",
+   "launch app",
+   "local build",
+   "mobile app",
+   "mobile device control",
+   "os build",
    "parallel sessions",
    "plan",
-   "screenshot",
-   "session video",
-   "public link",
    "private device",
-   "network profile",
-   "launch app",
-   "close app",
+   "public link",
+   "real device",
    "restart app",
-   "uninstall app",
-   "biometric",
-   "fingerprint",
-   "face id",
-   "camera injection",
-   "qr code",
-   "annotate",
-   "keyboard",
-   "keyboard open",
-   "home button",
-   "volume",
-   "hardware button",
-   "gps",
-   "location",
-   "foreground app",
-   "adb",
-   "device property",
-   "getprop",
-   "os build",
+   "screenshot",
+   "scroll",
+   "session video",
+   "swipe",
+   "tap",
    "upload apk",
+   "upload app",
+   "upload app for device",
    "upload ipa",
-   "local build",
-   "mobile device control",
-   "device control",
-   "drive a device"
+   "volume",
+   "webdriver"
   ],
   "base_url": "https://hub-cloud.browserstack.com",
   "auth": {
@@ -1100,8 +1090,9 @@
     "path": "/app-automate/upload",
     "mode": "write",
     "entity": "app_build",
-    "intent": "Upload an app build to App Automate from a public download link and get back the bs:// URL a session installs \u2014 use this to make a new .apk, .aab or .ipa available to devices.",
+    "intent": "Upload an app build to App Automate \u2014 the store device sessions install from, separate from App Live's \u2014 from a public download link, and get back the bs:// URL a session installs. Use this to make a new .apk, .aab or .ipa available to the devices an agent drives.",
     "guidance": [
+     "APP LIVE KEEPS A SEPARATE STORE. An app uploaded for App Live (manual, exploratory testing in a person's browser) is not available here, and one uploaded here does not appear in App Live \u2014 so when the app is going to be driven by you, tapped, typed into or scrolled by capability calls, upload it HERE, whatever the user calls the testing. The bs:// this returns is the one create_session installs.",
      "Only the download-link form can be used here. The same endpoint also accepts a multipart upload carrying the file itself, which this surface cannot send \u2014 so for a build that exists only on the caller's own machine, give them that multipart request to run themselves and take the bs:// url it returns. The upload answers with the bs:// url directly: there is no intermediate storage, no presigned url and no second call. There is no way to hand the bytes over from here.",
      "The url must be https and reachable by BrowserStack without credentials; a link behind a login fails on their side, not the caller's.",
      "Pass custom_id to give the build a stable name, then later sessions can use that name in place of the bs:// URL and always get the newest build under it.",
@@ -2892,6 +2883,7 @@
     "intent": "Upload an app build that is on this machine to App Automate and get back the bs:// URL a session installs \u2014 use this when the .apk, .aab or .ipa is a local file rather than a download link.",
     "guidance": {
      "shared": [
+      "APP LIVE KEEPS A SEPARATE STORE. An app uploaded for App Live (manual, exploratory testing in a person's browser) is not available here, and one uploaded here does not appear in App Live \u2014 so when the app is going to be driven by you, tapped, typed into or scrolled by capability calls, upload it HERE, whatever the user calls the testing. The bs:// this returns is the one create_session installs.",
       "Only .apk, .aab and .ipa are accepted.",
       "A large build takes minutes, because the upload does not return until the whole file has been sent.",
       "upload_app_build takes a public https link instead, and list_app_builds reuses a build already on the account \u2014 builds last 30 days."