feat(mcp): expose thread model selection#10557

merged2

agents/mcp-thin/questions

agents/mcp-thin/configuration

openedSep 7, 2026byJJulius Marminge

View on GitHubTwo-way sync enabledPR last imported 3d ago

1 unresolved thread · Jump to file

apps/server/src/mcp/toolkits/thread/handlers.ts:75–94 · `t3_thread_configure` adds new mutating backend behavior with non-trivial branching — the same `inst

Selected thread: apps/server/src/mcp/toolkits/thread/handlers.ts:94 — `t3_thread_configure` adds new mutating backend behavior with non-trivial branching — the same `instanceId` dispatches `thread.model-selection.set`, a different one dispatches `provider.switch` — and neither new tool has any behavioral test (`toolkits/core.test.ts` only walks the toolkit for unique names/JSON schema shape). Consider adding a focused test that drives both tools through the toolkit (as `OrchestratorMcpToolkit.integration.test.ts` does for `t3_thread_organize`), asserting the dispatched command type for the same-instance and cross-provider cases and that `t3_thread_configuration` reflects the resulting selection. Use test layers only for external services, not for the orchestrator command path itself. <sup>Posted via Macroscope — <a href="https://github.com/pingdotgg/t3code/runs/101849996987">Effect Service Conventions</a></sup>

0 / 4 viewed4 files changedLine totals unavailable

apps/server/src/mcp/toolkits/thread/handlers.ts · Earlier revision 5c8ac23d · right 75–94

Original diff

@@ -60,6 +60,38 @@ const readQuestion = Effect.fn("mcp.readQuestion")(function* (
   return { ...context, request, item };
 });
 export const ThreadToolkitHandlersLive = ThreadToolkit.toLayer({
+  t3_thread_configuration: (input) =>
+    Effect.gen(function* () {
+      const {
+        projection: { thread },
+      } = yield* readThread(input.threadId);
+      return {
+        threadId: thread.id,
+        modelSelection: thread.modelSelection,
+        runtimeMode: thread.runtimeMode,
+        interactionMode: thread.interactionMode,
+      };
+    }),
+  t3_thread_configure: (input) =>
+    Effect.gen(function* () {
+      const {
+        threads,
+        projection: { thread },
+      } = yield* readWritableThread();
+      const type =
+        thread.modelSelection.instanceId === input.modelSelection.instanceId
+          ? "thread.model-selection.set"
+          : "provider.switch";
+      const result = yield* threads
+        .dispatch({
+          type,
+          threadId: thread.id,
+          commandId: yield* newCommandId(),
+          modelSelection: input.modelSelection,
+        })
+        .pipe(Effect.mapError(unavailable));
+      return { sequence: result.sequence };
+    }),

apps/server/src/mcp/toolkits/thread/handlers.ts · right 75–94

macroscopeappBotSep 7, 2026

t3_thread_configure adds new mutating backend behavior with non-trivial branching — the same instanceId dispatches thread.model-selection.set, a different one dispatches provider.switch — and neither new tool has any behavioral test (toolkits/core.test.ts only walks the toolkit for unique names/JSON schema shape). Consider adding a focused test that drives both tools through the toolkit (as OrchestratorMcpToolkit.integration.test.ts does for t3_thread_organize), asserting the dispatched command type for the same-instance and cross-provider cases and that t3_thread_configuration reflects the resulting selection. Use test layers only for external services, not for the orchestrator command path itself.

^{Posted via Macroscope — Effect Service Conventions}

Julius MarmingeSep 7, 2026

Reviewed against the thin-wrapper scope requested by the maintainer. This handler selects one of the existing thread.model-selection.set/provider.switch commands; their execution and provider behavior stay in the already-tested orchestration services. The maintainer explicitly asked for shared MCP registration/scope/error tests rather than a separate behavior suite for every forwarding tool. No concrete incorrect command mapping was identified here. The core registration, capability, output and real MCP smoke tests cover the boundary; a new orchestration fixture for each selection branch would duplicate service coverage, so no source change is proposed.

macroscopeappBotSep 7, 2026

The underlying commands are tested, but neither MCP-level branch is covered: t3_thread_configure has no direct toolkit/integration invocation. The requested focused test is specifically for the handler’s instanceId dispatch decision, so this remains applicable.