Repository navigation
feat(mothership): discover every workspace mcp server without tagging - #9263
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
[Medium impact] The PR appears safe to merge; no actionable issues were found. SummaryAgent and plan chats can discover usable workspace MCP servers without tagging them.
No actionable issues were found. This review used code inspection; no tests were run.
|
The integration catalog only inspected MCP servers the user had /-tagged in the chat, so a configured server's tools were invisible to the agent until tagged. Claude Code, Codex, Cursor and OpenCode treat every configured server as available and discover tools lazily; built-in integrations here already did. In agent and plan chats, the catalog's MCP candidates are now every enabled, non-Credential-Group server the requester can list in the target workspace. Search stays MCP-free, and workflow-block requests (mcpExecution or selected operations) stay scoped to their explicit selections. - Untagged servers are discovered best-effort: cache-aside through the existing McpService discovery cache (in-flight deduped, negative cache honored), and a server that does not answer within 3s is skipped and logged while its discovery keeps running to warm the cache for the next query. - Tagged servers and an explicitly targeted server (service mcp:<id> or an exact tool id, which the worker re-resolves before executing) are still listed live and completely, and a targeted server still fails with its own error. - Tagged servers rank first among equally relevant matches via a preferredServices tie-break in projectIntegrationCatalog. - A permission group that disables MCP now drops MCP from broad requests and keeps built-in operations listed; targeted and workflow-block requests still fail with the permission error. Tagging persistence is unchanged; comments that said untagged servers stay unavailable now describe tags as a priority hint.
waleedlatif1
force-pushed
the
feat/mcp-discovery-without-tagging
branch
from
October 21, 2026 01:17
2d6bc32 to
a1bb62b
Compare
waleedlatif1
changed the base branch from
fix/mcp-discovery-resilience
to
staging
October 21, 2026 01:17
Merged
6 of 10 tasks
waleedlatif1
added a commit
that referenced
this pull request
Oct 21, 2026
… catalog resilient (#9266) * fix(mothership): keep untagged mcp discovery side-effect free and the catalog resilient Broad agent and plan catalog queries now discover every usable workspace MCP server (#9263), but a server's status, failure count, cooldown and OAuth row are shared by the workspace while its credentials resolve per requester. A member without a personal {{VAR}} the server references made discovery fail, which stamped the server failing and put it in a workspace-wide cooldown, so another member's tagged or targeted discovery and call re-resolution failed with McpServerCooldownError. For an OAuth server the requester never connected, discovery inserted an empty OAuth row and marked the server disconnected for everyone. - Best-effort (untagged, broad) discovery is a McpService mode that only reads shared health state: on failure it writes no status, failure count, cooldown or cache eviction, and on success only warms the tool cache. - Before reading the cache or connecting, it skips a server the requester cannot authenticate to: a referenced variable they have no value for (findMissingMcpConfigEnvVars, which records no secret usage), or an OAuth server with no authorized tokens (read, never created). Another member's cached tools are not served to them. - Tagged and targeted discovery keep today's health bookkeeping. - A failure listing the workspace's servers no longer fails the whole catalog: broad requests log it and keep built-ins and tagged servers; targeted MCP requests still fail with it. - A query with no content terms after tokenization (stop words only, or a script the tokenizer does not split) returns the unranked listing, as an empty query does, instead of total 0. Exact-ID ranking is unchanged. - A tagged server that is no longer usable is logged when dropped. * fix(mothership): gate best-effort mcp discovery on side-effect-free credential reads The best-effort gate read the OAuth row with loadOauthRow, which clears a column it cannot decrypt, so a broad catalog query after a key rotation erased the one grant every member shares. hasDecryptableOauthTokens reads the tokens column and tries to decrypt it without writing anything. findMissingMcpConfigEnvVars took a variable that failed to decrypt (which the environment snapshot reports as '') as present, so best-effort discovery connected with an empty credential instead of skipping. An empty effective value now counts as missing. * fix(mothership): keep the shared mcp oauth grant intact on best-effort refresh failures Best-effort discovery could still run the SDK's OAuth recovery while listing tools. A rejected refresh made it clear the tokens (and, for a rejected client, the registration) and start a new authorization flow, which disconnected the shared grant for every member. Its OAuth clients now use a SimMcpOauthProvider with preserveGrant, which refuses to invalidate credentials, register a client or start authorization before any write, so a failed refresh skips the server. A successful refresh still persists. It keeps the grant valid for everyone and must be saved where the server rotates refresh tokens. These clients are pooled apart from tracked ones. findMissingMcpConfigEnvVars counted every empty value as missing, but an empty variable is valid. Only a key the snapshot names in decryptionFailures whose effective value is empty now counts as missing.
This branch was previously deployed
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.
Summary
/-tagged. This matches Claude Code, Codex, Cursor and OpenCode, where configured MCP servers are available and their tools load on demand. Built-in integrations already work this way here.executeMcpToolUseCase, which authorizes per server), so the catalog lookup was the only gate.McpService's cache-aside path (5-minute cache,list_changedinvalidation, deduplicated in-flight requests, a cooldown for failed servers), and each is capped at 3s. A cold or slow server is skipped and logged without failing the query, and the background discovery warms the cache for the next one. Tagged servers and exact-toolId lookups stay live and complete, as before.mcpExecution/mcpToolIds) stay limited to the block's selections and Force. Credential Group servers still need an explicit managed connection.Stacked on #9260 (resilient per-server discovery). Merge that first; this PR then retargets
staging.Type of Change
Testing
catalog.test.tsblock "untagged workspace MCP servers":tsc --noEmitis clean. CI runs the rest.Checklist