Re-lands #456 with the problem it was reverted for fixed, and then narrows the TRA surface further on the back of live probing and the engineering test sheet.

#456 merged on 7 Oct and was reverted the same day (#466) because the TRA index shipped a large surface the product never meant to expose through MCP. This branch is cut from current main, reverts that revert, and applies the corrections on top — so the routing and OAuth work returns unchanged, and only the TRA index differs from what was already reviewed.

TRA: 502 → 254 capabilities

Entities 39 → 31. No destructive capabilities remain. Modes: read 222, write 32.

1. Scope (−234)

Filtered against the agreed list of 268 method+path pairs: 268 listed, 268 matched, nothing unmatched in either direction.

Matching on both halves matters. A path appears once per method in that list, and matching on path alone keeps every other verb the index documents for it — the first attempt did exactly that and kept 18 extra, all 12 DELETEs among them.

Removed whole areas: project settings and members, integrations, CI triggers, tokens, groups, the user and plan surfaces.

2. Duplicate routes (−12)

Twelve /ext/v1 capabilities and their /api/v1 twins declared the same response schema entry — not merely the same shape — so each pair was one capability behind two names. The external route survives and takes the clean name.

The shared entry is good evidence rather than an assumption, because the index authors modelled divergence where they found it: builds have their own PublicBuildDetailsResponse precisely because that route differs.

Confirmed against the engineering sheet, where all 12 _via_public_api rows are marked Deploying = Yes and their internal twins No.

3. Service-to-service only (−2)

create_project and save_test_rca are X-Service-API-Key routes. A customer username and access key can never call them, so shipping them offers a capability that always fails. create_project's own guidance already said so.

Naming: _via_public_api is gone

It was never a reliable signal — of the 35 capabilities on /ext/v1, only 24 carried it. It appeared where a name collision forced it, not where the external API was, so its absence meant nothing. All 24 resolved three ways:

• 12 collapsed — the surviving route takes the plain name; no marker needed once there is one capability per operation.
• 5 renamed for what they actually do: get_build_summary (8 fields vs get_build_details' 17), replace_view (requires the whole object where update_view patches), list_project_builds_by_project_id / _by_name (different filter sets), improve_test_rca (takes an instruction the retrigger route does not), list_build_history_with_defect_counts.
• 7 lost the suffix — no other capability held the name.

The ai-failure swap, worth reading twice

The internal route was list_build_ai_failure_test_runs_flat here but list_build_ai_failure_cluster_test_runs in the engineering test sheet. Dropping the suffix handed the external route the name the sheet already used for the internal one — one name, two endpoints, across two documents both treated as authoritative.

The internal now takes the sheet's name. The external becomes list_ai_failure_theme_test_runs, which is what it is: it accepts a theme or workflow id and, unlike its twin, cannot take testRunIds.

Guidance follows the names

Ten guidance strings pointed at capabilities that no longer exist — an agent following them would have asked for a name the registry cannot resolve.

get_build_summary claimed "the full public build record" while returning eight fields, three of which come back null. It now says what it gives, and carries what live probing found and nothing had documented:

status here is the build's LIFECYCLE ('finished'), not its outcome ('failed') as get_build_details reports it — the two routes answer different questions with the same field name.

With the suffix gone from the names, guidance is the only place left telling an agent which of a pair to reach for, so the remaining pairs now state their difference explicitly.

Everything else is #456 unchanged

Product routing (ambiguous prompts: 16.9% → 82.5% ask, failures 61.0% → 12.3% over a 201-prompt eval), the stateless signed routing token, product_choice removal, the central-OAuth extraction, and the askBrowserStackAI → capability-functions handoff rewrite. See #456 for detail.

Testing

1231 passing. All three products load: loadtesting 9 entities, tm 23, tra 31.

Worth knowing

• Breaking against 2.2.0-beta.1. That build has the _via_public_api names, and its list_build_ai_failure_cluster_test_runs points at the external route where this one points at the internal. Anything pinning those names changes behaviour silently.
• Routing shifts when a product halves. Words that settled on tra by weight of vocabulary now clash or settle elsewhere. The 201-prompt eval predates the trim and should be re-run before those numbers are quoted for this build.
• Two rows in the engineering sheet still read #N/A, and neither is a scoping gap: list_build_ai_failure_test_runs_by_ids is the same endpoint driven by testRunIds, and get_repo_setting_by_build_name is list_repo_settings, removed as out of scope.

🤖 Generated with Claude Code