@browserstack/mcp-server 2.2.2 → 2.3.0-beta.1

package/dist/tools/capability-registry/types.d.ts

@@ -116,6 +116,23 @@ export interface Capability {
     name?: string;
     method: string;
     path: string;
+    /**
+     * Which of the product's named `hosts` serves this one capability, when it is not the
+     * product's own `base_url`.
+     *
+     * A product is normally one host. App Automate is not: the account-level API (devices,
+     * app builds, plan, session records) answers on one origin and the Appium hub that
+     * drives the device answers on another, and neither serves the other's paths. Splitting
+     * them into two products would split one entity too — the session a hub capability
+     * creates is the session the account-level API reports on — and a caller holding the id
+     * would have to know it had changed products to use it.
+     *
+     * Unset means the product's own host, so every existing index is unaffected. A name that
+     * `hosts` does not define is refused by name at invocation rather than quietly falling
+     * back, because the fallback would send the call to a host that cannot serve the path and
+     * return a 404 that reads like the caller's mistake.
+     */
+    host?: string;
     mode: Mode;
     entity: string;
     path_params?: WireParam[];
@@ -155,6 +172,63 @@ export interface Capability {
      * suppression must not be ignored for arriving in an unexpected shape.
      */
     disabled?: boolean;
+    /**
+     * Withheld when the server is not running on the caller's own machine.
+     *
+     * Some capabilities only mean anything when the person and the process share a computer:
+     * one that reads a file the caller names is the clear case. On a remote server that path
+     * resolves against the OPERATOR's disk, so honouring it would read one user's files on
+     * another's behalf — the capability does not become unreliable there, it becomes wrong.
+     *
+     * Distinct from `disabled`, which withholds a capability everywhere. This one is a claim
+     * about where it can run, so the same artifact serves both deployments: a local server
+     * publishes it and a remote one does not.
+     *
+     * FAILS CLOSED in the same way, and takes the same `capability_disabled` path at
+     * invocation, so a caller holding the handle is told the absence is deliberate rather
+     * than hunting for a synonym.
+     */
+    local_only?: boolean;
+    /**
+     * What to do instead, on a surface where this capability cannot run.
+     *
+     * A `local_only` capability is NOT hidden on a remote server: the query that should find
+     * it still finds it, because an agent asked to upload a file from the user's machine
+     * needs to learn that the route exists and what replaces it here. What it loses is the
+     * means to call it — the parameters and response shapes are stripped at load, and
+     * invocation is refused — so the note is the whole of what remains.
+     *
+     * Write it as the instruction the caller should follow, not as an apology.
+     */
+    unavailable_note?: string;
+    /**
+     * FALSE when this build publishes the capability for reference but will not call it.
+     *
+     * Set by the loader, never authored: it is the surface's answer, not the artifact's.
+     */
+    invocable?: boolean;
+    /**
+     * How the request body is encoded. Absent means JSON, which is every capability today.
+     *
+     * `multipart` exists for endpoints that take the bytes of a file rather than a reference
+     * to one. A capability declaring it must also declare a `file` parameter, and should be
+     * `local_only`: the path names the caller's own machine.
+     */
+    encoding?: "multipart";
+    /**
+     * Send `{}` rather than no body at all, for an endpoint that takes no parameters.
+     *
+     * Normally a capability with nothing to send sends nothing, which is right for a REST API
+     * and wrong for W3C WebDriver: Chrome answers 400 "invalid argument" to a parameterless
+     * POST with the body omitted and 200 to the same call carrying `{}`. Appium tolerates the
+     * omission, which is why the identical capability needs this on Automate and not on App
+     * Automate.
+     *
+     * Opt-in per capability rather than a rule for every bodyless POST, because 27 of those
+     * exist across the shipped indexes and changing what reaches their products is not
+     * something this can verify.
+     */
+    send_empty_body?: boolean;
     paginated?: boolean;
     /** The largest page the operation declares. */
     max_page_size?: number;
@@ -313,6 +387,18 @@ export interface ProductIndex {
      * (see `discovery.probePath`); declare it when the derived choice would be wrong.
      */
     probe_path?: string;
+    /**
+     * Additional hosts this product is served from, by name, for capabilities that declare
+     * `host`.
+     *
+     * DISTINCT FROM `base_urls`, which is a list of CANDIDATES for one host — probed in turn
+     * so a region-sharded product lands on the account's own region. These are several hosts
+     * that all serve the product at once, each addressing a different part of it, and the
+     * capability says which it needs rather than the server discovering it.
+     *
+     * `base_url` remains the default for every capability that names no host.
+     */
+    hosts?: Record<string, string>;
     capabilities: Capability[];
     entities: Record<string, EntityDoc>;
     paging?: Record<string, PagingRule>;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@browserstack/mcp-server",
-  "version": "2.2.2",
+  "version": "2.3.0-beta.1",
   "description": "BrowserStack's Official MCP Server",
   "mcpName": "io.github.browserstack/mcp-server",
   "main": "dist/index.js",