Repository navigation
Batch MCP search discovery into a few product operations - #51
Merged
Merged
Conversation
An organization-wide MCP search discovered each app with two product operations, listAccounts and searchableTools, about 73 operations and 129 PGlite statements for 30 apps, all on the thread other sessions' calls share. Discovery now lists the searched apps' accounts with one listAccountsEach operation and reads their kept search rows with one searchableKept operation. The hosted backend runs the same checks per app from bulk reads: grant and policy as before, the caller's access and links for every app with accounts in one statement, the apps with their active versions in one, the selected accounts in one, the kept rows in one, and the actor's recheck of every app (appsResolving) in one. searchableKept never lists an app's tools: an app whose rows must be written, or that any check refuses, is left out and discovered on its own exactly as before, so stalled and slow apps stay isolated and every error is the one its own read reports. Local serves no kept rows this way and keeps its per-app reads. Measured on the native self-host host under taskpolicy -c background with 30 apps (10 with accounts): a search-heavy execute went from 73 operations and 129 statements to 11 and 16, the first search's discovery from about 550 ms to 140 ms, and canary MCP calls during it from p50 503 / max 724 ms to 434 / 498 ms. The new mcp-search-statements scenario checks that searching twelve apps makes the same four product operations and the same statements as six.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Round 17, Fix A: batch MCP search discovery. One org-wide
executesearch re-discovered every app on its firsttools.search, one app at a time. In production a single heavy call (traced4837beb…, 33 apps) made about 73 product operations on the product's single thread. Throttled locally to stand in for the 2-vCPU VM, that held other sessions' MCP calls for up to 2.5 s.Change
listAccountsEachlists every searched app's linked accounts in one operation, with each app's own success or error.searchableKeptserves, in one operation, the search rows the product already saved for those apps.appAccessOf), linked accounts and active version. The reads are batched instead: one statement for membership, policies and links of all apps (resourceAuthorityForLinksOfApps), one for apps and active versions, one for selected accounts, one for kept rows, and one for the actor's recheck.packages/mcp-auth) and the request forwarders handle both new operations. The local server batcheslistAccountsand keeps its old per-app search reads.Measured
Native self-host, CPU throttled with
taskpolicy -c background, 30 apps (10 with accounts) plus a canary app:Canary MCP latency (p50 / p95 / max):
In the 30 s loop this branch also completed 43 executes against 26 before. REST canary latency was about unchanged.
Tests
mcp-search-statements.spec.ts: searching 12 apps uses the same 4 operations and 9 statements as searching 6. With batching switched off it fails at 28 operations and 57 statements.ConnectionKeyRefusedin the OpenAPI document.bun run checkpasses.Deploy
Not deployed with this PR. It ships only if soaked and finished at least 24 h before the earliest confirmed cutover cutoff; otherwise it ships after the cutovers.