fix(mcp): thread run-scoped registry through discoverSchemas

[sroussey]

Summary

Commit 07389b9 ("fix(mcp): resolve auth credentials through the run-scoped registry") wired context.registry into mcpClientFactory.create(...) inside McpToolCallTask.execute / McpPromptGetTask.execute. But both tasks' execute() first calls this.discoverSchemas(context.signal, serverConfig), which internally calls mcpList(...) — a fresh new McpListTask(config).run(input) with NO run config. The nested run defaulted TaskRunner.runner.registry to globalServiceRegistry (packages/task-graph/src/task/TaskRunner.ts:94, 629), so in hosts that isolate per-(tenant, project) credential stores on the run-scoped registry, the discovery hop's bearer key never resolved against the right store.

Combined with the resolved ?? value fallback in resolveAuthSecrets (packages/mcp/src/util/McpAuthProvider.ts:388), the discovery listTools / listPrompts request sends the literal credential key name to the remote MCP server as a bearer token — leaking an internal identifier and breaking discovery against any server that gates list endpoints behind auth.

Fix (option a)

Picked option (a) — kept the mcpList(...) call inside discoverSchemas and threaded a registry through it:

• mcpList(input, config, runConfig) — new optional third arg, forwarded into McpListTask.run(input, runConfig). Keeps the standalone task as the single source of truth for client construction.
• McpToolCallTask.discoverSchemas(_signal, serverConfig, registry) and McpPromptGetTask.discoverSchemas(_signal, serverConfig, registry) accept the registry and forward it via mcpList(..., { registry }).
• Both execute() methods pass context.registry into discoverSchemas(...).

Option (b) — open the client inline and skip mcpList entirely — would have moved logic out of the task layer and duplicated the close/error handling. Option (a) is a strictly smaller change.

Test

New packages/test/src/test/mcp/McpDiscoveryRegistry.test.ts exercises the full discovery → list-tools → call-tool chain with a run-scoped credential store. Pattern follows the existing McpClientUtil.test.ts:

• Creates two scoped ServiceRegistry instances — a global with a WRONG-global-value bearer, a run-scoped with RIGHT-run-value.
• Stubs mcpClientFactory.create so that every client construction (discovery + main call) calls back into resolveMcpClientAuth(config, registry) and records the bearer header.
• Runs McpToolCallTask and McpPromptGetTask with task.run({}, { registry: runScoped }) and asserts the discovery hop's recorded bearer equals the run-scoped value, never the literal key.
• Adds a third case pinning the client_credentials client_secret resolution against the run-scoped registry — the same resolved ?? value fallback applies to that auth type, so the reviewer's coverage-gap concern is closed.

Test plan

• bun scripts/test.ts mcp vitest — 7 files, 106 tests, all pass (3 new tests in McpDiscoveryRegistry.test.ts).
• bunx tsgo -b packages/mcp packages/test — clean typecheck.
• CI green on main-targeted PR.

https://claude.ai/code/session_012goPYgXU4i7BF2k8aDatKP

---

Generated by Claude Code

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	62.25%	24967 / 40104
🔵	Statements	62.09%	25825 / 41588
🔵	Functions	63.23%	4721 / 7466
🔵	Branches	50.87%	12240 / 24058

File Coverage

No changed files found.

Generated in workflow #2555 for commit 9d9e0f2 by the Vitest Coverage Report Action