@browserstack/mcp-server 1.5.0-beta.1 → 1.5.0-beta.11

package/dist/tools/capability-registry/index-loader.d.ts

@@ -46,6 +46,8 @@ export declare class CapabilityRegistry {
     readonly provenance: Record<string, Provenance>;
     /** product -> "METHOD /path" -> capability */
     private readonly byEndpoint;
+    /** product -> capability name -> capability. Empty for products that publish no names. */
+    private readonly byName;
     constructor(index: RegistryIndex, provenance?: Record<string, Provenance>);
     static fromFile(file: string): CapabilityRegistry;
     /**
@@ -63,7 +65,19 @@ export declare class CapabilityRegistry {
     /** Per-product `{build_id, version}`, for logging and cache-busting only. */
     buildInfo(): Record<string, Provenance>;
     /**
-     * Find a capability by the endpoint it exposes — the published handle.
+     * Find a capability by its published name — the preferred handle.
+     *
+     * Names are unique within a product but not across products, so an ambiguous name is
+     * reported rather than resolved by load order. A name that exists in no index is
+     * `unknown_capability`: a distinct outcome from a name that exists elsewhere, because the
+     * caller's next move differs — search again, versus pass `product`.
+     */
+    byNameLookup(name: string, product?: string): {
+        product: string;
+        capability: Capability;
+    };
+    /**
+     * Find a capability by the endpoint it exposes — the handle for unnamed products.
      *
      * The endpoint is what searchCapability returns, so it is the only thing a caller can
      * hold. `unknown_endpoint` is a defined outcome rather than a generic failure: a caller

package/dist/tools/capability-registry/index-loader.js

@@ -107,6 +107,8 @@ export class CapabilityRegistry {
     provenance;
     /** product -> "METHOD /path" -> capability */
     byEndpoint = new Map();
+    /** product -> capability name -> capability. Empty for products that publish no names. */
+    byName = new Map();
     constructor(index, provenance = {}) {
         if (index?.schema_version !== SUPPORTED_SCHEMA_VERSION) {
             throw new IndexError(`unsupported index schema_version ${index?.schema_version}; this build reads ` +
@@ -119,10 +121,25 @@ export class CapabilityRegistry {
         this.provenance = provenance;
         for (const [product, bundle] of Object.entries(index.products)) {
             const lookup = new Map();
+            const names = new Map();
             for (const capability of bundle.capabilities) {
                 lookup.set(endpointKey(capability.method, capability.path), capability);
+                if (!capability.name)
+                    continue;
+                const clash = names.get(capability.name);
+                if (clash) {
+                    // A duplicate name makes one of the two permanently unreachable, and which one
+                    // wins would depend on array order. The export gates this, but a hand-edited or
+                    // stale artifact must not load and then silently drop an endpoint.
+                    throw new IndexError(`${product}: capability name '${capability.name}' is used by both ` +
+                        `${endpointKey(clash.method, clash.path)} and ` +
+                        `${endpointKey(capability.method, capability.path)}; names must be unique ` +
+                        `within a product`);
+                }
+                names.set(capability.name, capability);
             }
             this.byEndpoint.set(product, lookup);
+            this.byName.set(product, names);
         }
     }
     static fromFile(file) {
@@ -183,7 +200,45 @@ export class CapabilityRegistry {
         return this.provenance;
     }
     /**
-     * Find a capability by the endpoint it exposes — the published handle.
+     * Find a capability by its published name — the preferred handle.
+     *
+     * Names are unique within a product but not across products, so an ambiguous name is
+     * reported rather than resolved by load order. A name that exists in no index is
+     * `unknown_capability`: a distinct outcome from a name that exists elsewhere, because the
+     * caller's next move differs — search again, versus pass `product`.
+     */
+    byNameLookup(name, product) {
+        const matches = [];
+        for (const [owner, lookup] of this.byName) {
+            if (product && owner !== product)
+                continue;
+            const capability = lookup.get(name);
+            if (capability)
+                matches.push({ product: owner, capability });
+        }
+        if (matches.length === 0) {
+            // Say whether names are published at all for the product asked about: "no such name"
+            // and "this product does not name its capabilities" need different fixes.
+            const unnamed = [...this.byName]
+                .filter(([owner, lookup]) => (!product || owner === product) && lookup.size === 0)
+                .map(([owner]) => owner);
+            const hint = unnamed.length
+                ? ` ${unnamed.sort().join(", ")} ${unnamed.length > 1 ? "publish" : "publishes"} ` +
+                    `no capability names yet — call those by \`method\` and \`path\` instead.`
+                : " Search again — names come from searchCapability and describeEntity.";
+            throw new InvocationError(`unknown_capability: ${name}.${hint}`);
+        }
+        if (matches.length > 1 && !product) {
+            const owners = matches
+                .map((m) => m.product)
+                .sort()
+                .join(", ");
+            throw new InvocationError(`capability name '${name}' exists in several products (${owners}); pass product`);
+        }
+        return matches[0];
+    }
+    /**
+     * Find a capability by the endpoint it exposes — the handle for unnamed products.
      *
      * The endpoint is what searchCapability returns, so it is the only thing a caller can
      * hold. `unknown_endpoint` is a defined outcome rather than a generic failure: a caller

package/dist/tools/capability-registry/register.js

@@ -14,7 +14,7 @@ import { indexPaths, isEnabled, resolveBaseUrl } from "./config.js";
 import { fetchTransport } from "./egress.js";
 import { CapabilityRegistry, InvocationError, resolveResponses, } from "./index-loader.js";
 import { invoke } from "./resolve.js";
-import { searchCapabilities } from "./search.js";
+import { searchCapabilities, vocabularyOf } from "./search.js";
 export const PERMISSION_VALUES = ["not_asked", "granted", "denied"];
 /**
  * The tool-adder the server factory calls.
@@ -189,13 +189,17 @@ export function addCapabilityRegistryTools(server, deps, config) {
     tools.searchCapability = server.tool("searchCapability", "Find endpoints this surface can call, by plain language, optionally narrowed to one " +
         "entity, product or mode. " +
         `Currently loaded products: ${productList} — call listProducts for what each does. ` +
-        "Search matches the product's OWN words, not synonyms, so when a query returns " +
-        "nothing that fits, do not just rephrase it: call listEntities for the product and " +
-        "describeEntity on the closest entity, then search again using the vocabulary they " +
-        "return. Narrowing with `product` or `entity` sharpens results further. " +
-        "Each result carries the endpoint's `method` and `path` plus " +
-        "its parameters grouped into path_params / query / body under the spec's own names — " +
-        "pass them straight back to invokeEndpoint, no renaming. `intent` says what it does, " +
+        "Search matches the product's OWN words, not synonyms. When your words are not the " +
+        "product's, the response says so: `weak_match: true` with a `suggested_vocabulary` " +
+        "map of the product's entities and their aliases. Results are still returned, but " +
+        "treat them as unconfirmed — pick the closest entity from that map and search again " +
+        "using its vocabulary, or call describeEntity on it for the fuller picture. That one " +
+        "extra round trip is far cheaper than invoking the wrong capability. " +
+        "Narrowing with `product` or `entity` sharpens results further. " +
+        "Each result carries the capability's `name` — the handle you pass to " +
+        "invokeCapability — plus its `method` and `path` (use those two only when a result " +
+        "has no `name`), and its parameters grouped into path_params / query / body under " +
+        "the spec's own names. Pass them straight back, no renaming. `intent` says what it does, " +
         "`mode` tells you whether it writes, `product` says which product owns it, and " +
         "`responses` describes what a successful call returns, fully expanded. Results are " +
         "ranked and capped, and `truncated` says when more matched. Search before invoking.", {
@@ -229,7 +233,7 @@ export function addCapabilityRegistryTools(server, deps, config) {
     }, async ({ query, entity, product, mode, limit, include_responses }) => {
         track("searchCapability");
         const selection = (include_responses || "success");
-        const { hits, ...rest } = searchCapabilities(registry.index.products, query, {
+        const { hits, weak, top_matched, ...rest } = searchCapabilities(registry.index.products, query, {
             entity,
             product,
             mode: mode,
@@ -255,24 +259,52 @@ export function addCapabilityRegistryTools(server, deps, config) {
                 };
             }),
             ...rest,
+            // WHEN THE MATCH IS WEAK, HAND OVER THE VOCABULARY.
+            //
+            // A vocabulary miss returns a full page of confident-looking hits — nothing in the
+            // shape of the response says the caller's word does not exist in this product. This
+            // is that signal, plus the fix in the same round trip: the caller is a model, and it
+            // maps "bucket" to "folder" instantly once it can see the entity list.
+            //
+            // Additive, never a replacement — the results are still there, and the caller is
+            // told to re-search rather than to trust this. That is what makes a generous
+            // threshold safe.
+            ...(weak
+                ? {
+                    weak_match: true,
+                    suggested_vocabulary: vocabularyOf(registry.index.products, product),
+                    hint: "Nothing matched the product's own words strongly (best term score " +
+                        `${top_matched.toFixed(1)}). The results below may not answer the ` +
+                        "question. Re-search using a term from suggested_vocabulary, or call " +
+                        "describeEntity on the closest entity for its full vocabulary.",
+                }
+                : {}),
         });
     });
-    tools.invokeEndpoint = server.tool("invokeEndpoint", "Call an endpoint returned by searchCapability. Pass `method` and `path` exactly as " +
-        "given, with arguments grouped into path_params / query / body under the spec's own " +
-        "names. One call makes exactly one request and returns the product's own response " +
-        "untouched; when `completed` is false there is another page, which you fetch by " +
-        "sending the endpoint's own page parameter. If the endpoint's mode is 'write' you " +
-        "MUST ask the user first, then " +
-        "resend with user_permission='granted' and a change_summary; both are recorded. " +
-        "Endpoints whose mode is 'destructive' (deletes) are refused outright — archiving, " +
-        "closing and merging are ordinary writes and DO run, so read the mode and intent " +
-        "before confirming with the user.", {
+    tools.invokeCapability = server.tool("invokeCapability", "Call a capability returned by searchCapability or describeEntity. Pass `name` exactly " +
+        "as given — that is the handle. Only when a result carries no `name` (some products " +
+        "do not publish them yet) pass `method` and `path` instead, exactly as returned. " +
+        "Arguments go in path_params / query / body under the spec's own names. One call " +
+        "makes exactly one request and returns the product's own response untouched; when " +
+        "`completed` is false there is another page, which you fetch by sending the " +
+        "capability's own page parameter. If the mode is 'write' you MUST ask the user " +
+        "first, then resend with user_permission='granted' and a change_summary; both are " +
+        "recorded. Capabilities whose mode is 'destructive' (deletes) are refused outright — " +
+        "archiving, closing and merging are ordinary writes and DO run, so read the mode and " +
+        "intent before confirming with the user.", {
+        name: z
+            .string()
+            .optional()
+            .describe("The capability's published name, exactly as returned (e.g. 'create_test_run_v1'). " +
+            "Preferred over method/path."),
         method: z
             .string()
-            .describe("HTTP method, exactly as searchCapability returned it."),
+            .optional()
+            .describe("HTTP method — only for capabilities returned without a `name`."),
         path: z
             .string()
-            .describe("Path with {placeholders} intact, exactly as returned."),
+            .optional()
+            .describe("Path with {placeholders} intact — only for capabilities returned without a `name`."),
         path_params: z
             .record(z.string(), z.any())
             .optional()
@@ -287,8 +319,8 @@ export function addCapabilityRegistryTools(server, deps, config) {
             .describe("Body fields, under the spec's names."),
         product: productArg()
             .optional()
-            .describe(`Which product owns the endpoint (${productList}). searchCapability returns it ` +
-            "on every result; required only when two products share a path."),
+            .describe(`Which product owns the capability (${productList}). searchCapability returns it ` +
+            "on every result; required only when two products share a name or a path."),
         user_permission: z
             .enum(PERMISSION_VALUES)
             .optional()
@@ -298,7 +330,7 @@ export function addCapabilityRegistryTools(server, deps, config) {
             .optional()
             .describe("What will change. Required for writes."),
     }, {
-        title: "Invoke Endpoint",
+        title: "Invoke Capability",
         // Not read-only: this is the one tool that writes. Never destructive, because
         // destructive endpoints are refused before binding — the refusal is enforced here,
         // not merely hinted at. Not idempotent: it creates, clones and starts runs. Closed
@@ -308,9 +340,20 @@ export function addCapabilityRegistryTools(server, deps, config) {
         idempotentHint: false,
         openWorldHint: false,
     }, async (input) => {
-        track("invokeEndpoint");
+        track("invokeCapability");
         try {
-            const { product, capability } = registry.byEndpointLookup(input.method, input.path, input.product);
+            // Either handle resolves to the same capability. `name` wins when both are sent,
+            // rather than cross-checking them: a caller pasting a stale path alongside a good
+            // name should still reach the right operation, which is the point of naming.
+            if (!input.name && !(input.method && input.path)) {
+                return failed("pass `name` — or, for a capability returned without one, both `method` and " +
+                    "`path`, exactly as searchCapability returned them");
+            }
+            const { product, capability } = input.name
+                ? registry.byNameLookup(input.name, input.product)
+                : registry.byEndpointLookup(input.method, input.path, input.product);
+            /** What to call it in errors — the handle the caller actually used. */
+            const handle = capability.name || `${capability.method} ${capability.path}`;
             const args = {
                 path_params: input.path_params,
                 query: input.query,
@@ -318,8 +361,7 @@ export function addCapabilityRegistryTools(server, deps, config) {
             };
             if (capability.mode === "destructive") {
                 // Refused before binding, so consent is never sought for something that cannot run.
-                return failed(`${input.method} ${input.path} is a destructive operation and is not available ` +
-                    `through this surface`);
+                return failed(`${handle} is a destructive operation and is not available through this surface`);
             }
             if (capability.mode === "write") {
                 const permission = input.user_permission || "not_asked";
@@ -345,8 +387,8 @@ export function addCapabilityRegistryTools(server, deps, config) {
         catch (error) {
             if (error instanceof InvocationError)
                 return failed(error.message);
-            logger.error("invokeEndpoint failed: %s", error instanceof Error ? error.message : String(error));
-            return failed("that endpoint could not be invoked");
+            logger.error("invokeCapability failed: %s", error instanceof Error ? error.message : String(error));
+            return failed("that capability could not be invoked");
         }
     });
     return tools;

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

@@ -36,8 +36,9 @@ export declare function wantsCollection(query: string | undefined): boolean;
  *
  * Pagination is the reliable signal — a paged operation is a listing by construction. The
  * plural terminal path segment is a weaker fallback for unpaged collections. (The Python
- * side used the capability NAME here; the artifact publishes no name, and the path's own
- * terminal noun carries the same signal because operationIds were derived from it.)
+ * side used the capability NAME here. tm now publishes one, but its verbs are not
+ * consistent — the endpoint that lists folders is `get_root_folders_v1` — so the path's
+ * terminal noun remains the better signal.)
  */
 export declare function isCollection(capability: Capability): boolean;
 /**
@@ -45,7 +46,7 @@ export declare function isCollection(capability: Capability): boolean;
  *
  * Attribution is not decoration: the response tables are per product, so dereferencing a
  * hit's schemas needs to know whose tables to read. It is also what lets a caller pass
- * `product` to invokeEndpoint when two products share an endpoint — until now search
+ * `product` to invokeCapability when two products share an endpoint — until now search
  * ranked across products and then threw away the only thing that could disambiguate them.
  */
 export interface SearchHit {
@@ -56,7 +57,38 @@ export interface SearchResult {
     hits: SearchHit[];
     truncated: boolean;
     total_matched: number;
+    /**
+     * The best pre-penalty term score, and whether it is weak enough to doubt.
+     *
+     * A vocabulary miss does NOT look like a miss from the outside: "make a new bucket for my
+     * tests" returns a full page of eight confident hits, exactly like a query that worked,
+     * because containment finds *something* for `make`, `new` and `tests`. The only thing that
+     * separates them is how little the match is worth.
+     */
+    top_matched: number;
+    weak: boolean;
 }
+/** One entity's caller-facing vocabulary: what it is called, and what else it is called. */
+export interface VocabularyEntry {
+    entity: string;
+    title?: string;
+    aliases?: string[];
+}
+/**
+ * The product's vocabulary, for a caller whose words are not the product's words.
+ *
+ * THE ONE FAILURE LEXICAL SEARCH CANNOT FIX. "make a new bucket for my tests" wants the
+ * folder-create capability, and `bucket` appears nowhere in the index — no scoring change
+ * reaches it, because the word is simply absent. What CAN reach it is the caller: it is a
+ * language model, and given tm's entity list it maps bucket -> folder without effort. It
+ * just cannot guess the list unprompted.
+ *
+ * Aliases only, deliberately. They are the vocabulary map — 19 entities in ~1.5KB, against a
+ * response that is routinely 38KB. The entity `key_facts` are richer prose but ten times the
+ * size, and a caller who needs them can ask describeEntity once it knows which entity to ask
+ * about — which is exactly what this hands over.
+ */
+export declare function vocabularyOf(products: Record<string, ProductIndex>, only?: string): Record<string, VocabularyEntry[]>;
 export declare function searchCapabilities(products: Record<string, ProductIndex>, query?: string, options?: {
     entity?: string;
     product?: string;

package/dist/tools/capability-registry/search.js

@@ -165,8 +165,9 @@ export function wantsCollection(query) {
  *
  * Pagination is the reliable signal — a paged operation is a listing by construction. The
  * plural terminal path segment is a weaker fallback for unpaged collections. (The Python
- * side used the capability NAME here; the artifact publishes no name, and the path's own
- * terminal noun carries the same signal because operationIds were derived from it.)
+ * side used the capability NAME here. tm now publishes one, but its verbs are not
+ * consistent — the endpoint that lists folders is `get_root_folders_v1` — so the path's
+ * terminal noun remains the better signal.)
  */
 export function isCollection(capability) {
     if (capability.paginated)
@@ -177,6 +178,26 @@ export function isCollection(capability) {
     const tail = segments[segments.length - 1] || "";
     return tail.endsWith("s") && !tail.endsWith("ss");
 }
+/**
+ * Does this capability's mode answer what the caller asked to DO?
+ *
+ * `destructive` counts as a write. It has to: `modeHint` reads "delete" and "remove" as
+ * WRITE verbs, but a delete endpoint's mode is `destructive`, so a strict equality check
+ * penalised every destructive capability by 20 FOR BEING A DELETE — on exactly the queries
+ * that wanted one. "bulk delete test cases" scored 15.8 on terms, the highest of any missed
+ * query in the eval, and still fell out of the top 8.
+ *
+ * That accounted for 15 of the eval's 36 misses. The mode hint exists to separate reading
+ * from changing; destructive is changing.
+ *
+ * A read hint still refuses destructive, which is the useful half: "show me the test plans"
+ * must not surface a delete.
+ */
+function satisfiesHint(mode, hint) {
+    if (hint === "write")
+        return mode === "write" || mode === "destructive";
+    return mode === hint;
+}
 /** Everything a caller might say that lives on a parameter rather than in the prose. */
 function parameterText(capability) {
     const parts = [];
@@ -195,7 +216,49 @@ function parameterText(capability) {
     }
     return parts.join(" ");
 }
-/** Path words stand in for the capability name as the identity haystack. */
+/**
+ * Path words are the identity haystack. The published `name` is deliberately NOT scored.
+ *
+ * That is a measured result, not an oversight. tm now names every capability, and adding
+ * the name to the ranking was tried three ways against tests/fixtures/search-eval.json,
+ * which the pre-names index serves 18/18:
+ *
+ *   folded into this field, weight 6          17/18
+ *   its own field, weights 1 / 2 / 3 / 4 / 6  17 / 17 / 17 / 17 / 16
+ *   only the words the path lacks, 1..6       17 / 16 / 15 / 15 / 14
+ *
+ * Every variant loses, for two reasons. The nouns in a name are the route restated — the
+ * name is snake-cased from the operationId, itself derived from the path — so scoring them
+ * again rewards verbose names for repeating themselves: `get_test_cases_for_v1_test_run`
+ * displaced `create_test_result_for_test_case` on "record a pass or fail for a test case in
+ * a run", putting a read above the write that answers it. And what a name adds beyond the
+ * route is mostly its verb, which tm applies inconsistently (`get_root_folders_v1` lists,
+ * `list_folder_test_cases_v1` also lists), so the verb is noise as often as signal.
+ *
+ * The query this was meant to fix, "list all projects", only went 7 -> 4 even where it
+ * helped: `projects` is in 156 of 173 paths as a scope prefix, so rarity correctly values it
+ * near zero and no amount of name weighting recovers it. That one is fixed instead by the
+ * terminal-segment bonus in `score`, which tells "is that thing" from "is scoped by it".
+ *
+ * Revisit when a product ships a consistent verb convention — then the verb becomes signal.
+ */
+/**
+ * The terminal path segment — the thing this endpoint is actually ABOUT.
+ *
+ * A REST path mixes two different things: the resources it is SCOPED BY, and the resource it
+ * ADDRESSES. Only the last segment is the latter. See the bonus in `score` for why that
+ * distinction matters and why it is applied flat rather than weighted.
+ *
+ * Trailing placeholders are skipped, so `/test-cases/{id}` is still about test cases.
+ * Action tails (`close`, `edit`, `delete`) are kept rather than skipped: for "close a test
+ * run" the tail IS the most specific thing the caller said.
+ */
+function resourceText(capability) {
+    const segments = capability.path
+        .split("/")
+        .filter((s) => s && !s.startsWith("{") && s !== "api");
+    return (segments[segments.length - 1] || "").replace(/[-_]/g, " ");
+}
 function identityText(capability) {
     return capability.path
         .split("/")
@@ -225,6 +288,51 @@ function rarity(documents, forms) {
     const total = documents.length || 1;
     return Math.log((total + 1) / (df + 1)) / Math.log(total + 1);
 }
+/**
+ * Sized to sit alongside the mode (+6) and cardinality (+8) constants, not to dwarf them.
+ * The pinned eval is unchanged at every value from 2 to 14 — the bonus only ever fires on
+ * queries it does not cover — so this was chosen on the wider sweep: at 10, "close a test
+ * run" starts pulling `close_exploratory_session` into second place on the tail match alone.
+ */
+const RESOURCE_BONUS = 6;
+/**
+ * How much a cardinality guess is worth. It used to be 8, and it should not have been.
+ *
+ * `isCollection` is a GUESS read off the URL, and the index carries nothing better: of 88
+ * read capabilities, zero declare an array in their response schema, and `paginated` — the
+ * one signal that looks trustworthy — is true for `get_report_detail`, a single-record
+ * endpoint. There is no derived cardinality in this artifact to appeal to.
+ *
+ * At ±8 that guess swung 16 points and buried 11 correct answers: `/test-runs/closed` and
+ * `/{entity}/search` are listings whose last path segment is not a plural noun, `users-v2`
+ * is plural with a version suffix in the way, and the count endpoints answer "how many"
+ * with a scalar. All were penalised for what they are called.
+ *
+ * The fix is not a better classifier — a qualifier word-list would encode tm's route
+ * conventions into generic code and rot on the next product. It is to stop betting so much
+ * on an unreliable signal. Swept against the eval, holding top1 at 138 with no ceiling
+ * violations: ±7 retires 1, ±6 retires 2, ±5 retires 5, ±4 retires 6. Below that it starts
+ * costing more than it returns — ±3.5 retires 8 but breaks a case, ±3 breaks two.
+ */
+const CARDINALITY = 4;
+/**
+ * The mode penalty stays at 20, unlike the cardinality one — it is earned.
+ *
+ * Where `isCollection` is a guess off the URL, `modeHint` is measured right: across the
+ * eval it agrees with the correct answer's mode 125 times and disagrees 3. A signal that
+ * accurate deserves to be decisive.
+ *
+ * Sweeping it 20 -> 6 retires none of the three misses filed against it and regresses
+ * nothing, which says the penalty is not what holds them back. It isn't: they sit at ranks
+ * 41, 62 and 78 of the matched set, far below anything a constant could lift. All three
+ * are vocabulary gaps wearing a mode-penalty label — "what gets removed" wants a path
+ * spelled `rm-summary`, "get rid of" wants `delete`, and "the option set" wants what the
+ * product calls a `dataset`. The target barely matches on TERMS; the hint is incidental.
+ *
+ * Left at 20 deliberately. There was no evidence for moving it, and an unjustified constant
+ * is how this scorer got into trouble in the first place.
+ */
+const MODE_PENALTY = 20;
 function score(capability, wanted, weights, aliases, hint, plural) {
     if (wanted.length === 0)
         return { matched: 1, ranked: 1 };
@@ -273,14 +381,85 @@ function score(capability, wanted, weights, aliases, hint, plural) {
         }
     }
     const matched = ranked;
-    if (hint && capability.mode !== hint)
-        ranked -= 20;
-    else if (hint && capability.mode === hint)
-        ranked += 6;
+    // THE ENDPOINT IS THAT THING, not merely scoped by it.
+    //
+    // A REST path mixes the resources it is SCOPED BY with the one it ADDRESSES. `projects` is
+    // in 156 of tm's 173 paths but is the terminal segment in 3, so whole-corpus rarity —
+    // correctly — values it near nothing, and every project-scoped listing scored the same as
+    // the projects listing itself. The top 8 for "list all projects" spanned 15.9 to 14.8,
+    // where +8 collection and +6 mode already account for 14: the term signal was ~1 point of
+    // noise and the right answer sat 7th.
+    //
+    // Flat, and deliberately NOT rarity-scaled. Rarity would reintroduce the same problem in
+    // reverse — a rare scope noun outranking the real target, which is exactly how a weighted
+    // version of this put `/projects/{id}/folders` above `/folder/{id}/test-cases` for "tc list
+    // for a folder". This asks one yes/no question instead: is the caller's own word the last
+    // thing in the path?
+    //
+    // Equality is against the QUERY's forms, never the haystack's — the same one-directional
+    // rule as containment. `projects` is in forms("projects"), so the projects listing hits;
+    // `folders` is not in forms("folder"), so a folder-scoped query does not drag in the
+    // folders listing.
+    const tail = terms(resourceText(capability));
+    if (tail.length &&
+        wanted.some((forms) => tail.every((word) => forms.includes(word)))) {
+        ranked += RESOURCE_BONUS;
+    }
+    if (hint)
+        ranked += satisfiesHint(capability.mode, hint) ? 6 : -MODE_PENALTY;
     if (plural)
-        ranked += isCollection(capability) ? 8 : -8;
+        ranked += isCollection(capability) ? CARDINALITY : -CARDINALITY;
     return { matched, ranked };
 }
+/**
+ * Below this, the caller is probably not speaking the product's language.
+ *
+ * Measured on tm: vocabulary misses top out at 1.98–2.15 ("where do my things live", "make a
+ * new bucket for my tests") while queries that work reach 6.5–12. The two ranges do NOT
+ * separate cleanly — "list all projects" scores 1.58 and is nonetheless answered correctly
+ * at rank 1, because `projects` is in 156 of 173 paths and worth almost nothing.
+ *
+ * So this is set generously and false positives are accepted, which is sound only because
+ * the vocabulary block is ADDITIVE: it arrives next to the results, never instead of them.
+ * Over-triggering costs ~1.5KB against a response that is routinely 38KB; under-triggering
+ * costs the caller a wrong answer with no hint that it is wrong. Those are not symmetric.
+ */
+const WEAK_MATCH = 3;
+/**
+ * The product's vocabulary, for a caller whose words are not the product's words.
+ *
+ * THE ONE FAILURE LEXICAL SEARCH CANNOT FIX. "make a new bucket for my tests" wants the
+ * folder-create capability, and `bucket` appears nowhere in the index — no scoring change
+ * reaches it, because the word is simply absent. What CAN reach it is the caller: it is a
+ * language model, and given tm's entity list it maps bucket -> folder without effort. It
+ * just cannot guess the list unprompted.
+ *
+ * Aliases only, deliberately. They are the vocabulary map — 19 entities in ~1.5KB, against a
+ * response that is routinely 38KB. The entity `key_facts` are richer prose but ten times the
+ * size, and a caller who needs them can ask describeEntity once it knows which entity to ask
+ * about — which is exactly what this hands over.
+ */
+export function vocabularyOf(products, only) {
+    const out = {};
+    for (const [name, bundle] of Object.entries(products)) {
+        if (only && name !== only)
+            continue;
+        const entries = [];
+        for (const [entity, doc] of Object.entries(bundle.entities || {})) {
+            const aliases = (doc.aliases || []);
+            entries.push({
+                entity,
+                ...(doc.title
+                    ? { title: doc.title }
+                    : {}),
+                ...(aliases.length ? { aliases } : {}),
+            });
+        }
+        if (entries.length)
+            out[name] = entries;
+    }
+    return out;
+}
 export function searchCapabilities(products, query, options = {}) {
     const limit = options.limit && options.limit > 0 ? options.limit : 8;
     // Forms are computed once per query, not per capability: 173 capabilities x 6 haystacks
@@ -332,11 +511,17 @@ export function searchCapabilities(products, query, options = {}) {
         }
     }
     scored.sort((a, b) => b.ranked - a.ranked || a.capability.path.localeCompare(b.capability.path));
+    // Ranked order decides the page; the best TERM score decides confidence. They are
+    // different questions: the mode and cardinality constants can lift a weakly-matched
+    // capability to the top of a page that is entirely wrong.
+    const topMatched = scored.reduce((best, s) => Math.max(best, s.matched), 0);
     return {
         hits: scored
             .slice(0, limit)
             .map(({ product, capability }) => ({ product, capability })),
         truncated: scored.length > limit,
         total_matched: scored.length,
+        top_matched: topMatched,
+        weak: wanted.length > 0 && topMatched < WEAK_MATCH,
     };
 }

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

@@ -67,6 +67,17 @@ export interface ResponseDoc extends ComponentRef {
 }
 /** A capability, keyed by the endpoint it exposes. There is deliberately no name. */
 export interface Capability {
+    /**
+     * The caller-facing handle — the snake-cased `operationId`, unique within its product.
+     *
+     * This is what `invokeCapability` takes, and what `entities[*].capabilities[]` lists. It
+     * is stable where a route is not: `/edit` becoming `/edit-v2` must not break a caller
+     * holding a handle.
+     *
+     * OPTIONAL because not every product publishes it yet — loadtesting's index carries none.
+     * For those, the endpoint remains the handle, so nothing may assume this is present.
+     */
+    name?: string;
     method: string;
     path: string;
     mode: Mode;
@@ -108,6 +119,19 @@ export interface EntityDoc {
         entity?: string;
         via?: string;
     }[];
+    /**
+     * What a caller gets wrong about this ENTITY, as opposed to one operation.
+     *
+     * The entity-wide half of guidance: "a run's `id` is the display string, take `uuid`"
+     * holds for every capability returning a run, so it is stated once here rather than
+     * copied onto each capability's `guidance` — which would repeat across ~20 records and,
+     * since guidance is a search haystack, dilute ranking with boilerplate.
+     *
+     * Filtered at build time and often absent: of tm's 155 authored facts, 73 are publishable
+     * as written and the rest name routes, HTTP verbs or wire-shaped parameters. Absent means
+     * "none passed", never an error.
+     */
+    key_facts?: string[];
     [key: string]: unknown;
 }
 /**

package/package.json

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