docs(runtime): record the dated deferral of task-augmented MCP tool calls (#369) - #394
Merged
Conversation
🦋 Changeset detectedLatest commit: a98a7a8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
commit: |
…alls (#369) The installed MCP SDK (@modelcontextprotocol/server 2.0.0) ships only the 2025-11-25 Tasks wire vocabulary with no task runtime, and the 2026-07-28 revision moves tasks into the io.modelcontextprotocol/tasks extension (SEP-2663) with tasks/result removed. Rather than hand-roll the protocol outside the SDK's typed surface, record the deferral with its SDK pin, spec facts, and upstream tracker, and enforce it: - rsc-runtime sentinel test pins the audited SDK version, asserts the SDK exposes only task wire vocabulary, that the typed client cannot issue tasks/*, that createRscMcpServer never advertises `tasks` even to a tasks-negotiating client, that a task-augmented tools/call is processed as an ordinary request, and that tasks/* answer -32601. - mcp-in-memory projection tests prove the generated server stays fail-closed the same way, plus a @ts-expect-error sentinel on the typed setRequestHandler('tasks/get') overload so `pnpm typecheck` fails the day the SDK admits task methods. - docs/mcp-conformance.md, docs/entry-conventions.md, and the runtime README record the deferral and the exact unblock condition.
ScriptedAlchemy
force-pushed
the
feat/369-mcp-tasks
branch
from
September 3, 2026 06:39
4ddb4e7 to
a98a7a8
Compare
Owner
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
This was referenced Sep 3, 2026
Closed
ScriptedAlchemy
added a commit
that referenced
this pull request
Sep 4, 2026
…get, tasks/result, tasks/cancel, tasks/list (#369) Tool routes opt in with config.execution.taskSupport ('optional' | 'required', validated as AB4836 and advertised in tools/list). The generated server answers a task-augmented call with a CreateTaskResult at once and keeps the Flight render behind the task: tasks/get reports status and the last render progress, tasks/result blocks for the same CallToolResult the ordinary call returns, tasks/cancel interrupts the render through its AbortSignal, tasks/list lists the session's tasks. Clients that never ask for a task see no change; a server whose tools never opted in advertises no tasks capability. Replaces the dated #394 deferral sentinels with the lifecycle proofs at the unit, mcp-in-memory, and packed-stdio levels.
ScriptedAlchemy
added a commit
that referenced
this pull request
Sep 4, 2026
…get, tasks/result, tasks/cancel, tasks/list (#369) (#550) * feat(mcp): serve task-augmented tools/call — CreateTaskResult, tasks/get, tasks/result, tasks/cancel, tasks/list (#369) Tool routes opt in with config.execution.taskSupport ('optional' | 'required', validated as AB4836 and advertised in tools/list). The generated server answers a task-augmented call with a CreateTaskResult at once and keeps the Flight render behind the task: tasks/get reports status and the last render progress, tasks/result blocks for the same CallToolResult the ordinary call returns, tasks/cancel interrupts the render through its AbortSignal, tasks/list lists the session's tasks. Clients that never ask for a task see no change; a server whose tools never opted in advertises no tasks capability. Replaces the dated #394 deferral sentinels with the lifecycle proofs at the unit, mcp-in-memory, and packed-stdio levels. * feat(workbench): drive task-augmented tool calls from the MCP page — run as task, poll tasks/get, fetch tasks/result, cancel, list (#369) The browser session controller, the dev session routes, and the dev McpSession gain the typed task operations (callToolTask, getTask, getTaskResult, cancelTask, listTasks) over the same epoch-bound operation vocabulary; the MCP page offers a Run-as-task toggle for tools that advertise execution.taskSupport, folds every task answer from the invocation history into a Tasks panel, and polls working tasks at the server's suggested interval. The host-test example gains a task-capable slow probe (execution.taskSupport optional) so a host's handling of long-running tools can be observed; the new desktop browser acceptance drives it through the real generated stdio server. * docs(mcp): document long-running tools as tasks, record per-host task-call evidence, lift the #394 deferral (#369) * build(agent-bundle): emit mcp-tasks as its own rslib entry so the bundled mcp-server-runtime chunk stays free of the rslib runtime import A generated artifact bundles dist/mcp-server-runtime.js; when rslib concatenated the task module into that chunk it added an `import { __webpack_require__ } from './rslib-runtime.js'` whose identifiers shadow the artifact bundler's own runtime, and the packed stdio entry failed at load (`__webpack_modules__[moduleId] is not a function`). Proven by the packed-stdio proof, which now also drives the task journey. * chore: reference #550 in the changeset * test(workbench): drop the failure-screenshot debugging hook from the task e2e * fix(mcp): keep required tools callable on a session without the core Tasks utility; clear a task's stale error on a later successful answer Codex review of 3928a61: the required-tool rejection now applies only on a task-capable session (2025-11-25 with the capability declared) — elsewhere every call, required tools included, is the ordinary request and task metadata is ignored; the Workbench task fold drops a prior error when a later tasks/get, tasks/list, or tasks/result succeeds, so polling resumes. * docs(agent-bundle): record the task-augmented lifecycle proof in the README testing story (#369)
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
1 participant
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
Issue #369 asked for task-augmented MCP tool calls (
CreateTaskResult→tasks/get/tasks/result,tasks/cancelinto the rendererAbortSignal) — the #96 acceptance remainder. The assessment lands on the honest-deferral branch: the installed SDK has no task runtime to build on, so this PR records the deferral precisely and makes it impossible to go stale silently, instead of hand-rolling the protocol outside the SDK's typed surface.2025-11-25; generated servers use@modelcontextprotocol/server@2.0.0/client@2.0.0/core@2.0.0. The SDK declares task methods "2025-11-25 wire vocabulary with no SDK runtime" —request(),setRequestHandler(),ctx.mcpReq.send()excludetasks/*; runtime exports are onlyRELATED_TASK_META_KEYand a@deprecatedisTaskAugmentedRequestParams; noTaskStore/experimental.tasks. The2026-07-28revision moved tasks into theio.modelcontextprotocol/tasksextension (SEP-2663) and removedtasks/result. Upstream tracker: typescript-sdk#2189 (+ #2598, #2637).tasks(even to a client that negotiated it); a task-augmentedtools/callis processed as an ordinary request with no task handle (the 2025-11-25 fallback MUST);tasks/get|result|list|cancelanswer-32601. feat(runtime): MCP progress projector and warm-runtime proofs (#96) #175's progress/final contract is untouched.packages/rsc-runtime/tests/mcp-tasks-deferral.test.tspins the audited SDK version and asserts each fact against the installed packages;mcp-in-memory.test.tscarries the two behavioural proofs on the generated server plus a@ts-expect-erroron the typedsetRequestHandler('tasks/get', …)overload (verified load-bearing: removing it failstsc).docs/mcp-conformance.mdwith the SDK pin, spec facts, upstream links, and the exact unblock condition;docs/entry-conventions.mdstdio lifecycle shell; runtime README; changeset for@agent-bundle/runtime.No production code changes. Closes nothing — #369 stays open with the unblock condition.
Evidence
pnpm typecheck✅ (and negative check: dropping the@ts-expect-erroryieldsTS2345: '"tasks/get"' is not assignable to parameter of type 'RequestMethod')pnpm lint✅ 0 errors / 0 warningsrstest packages/rsc-runtime/tests/mcp-tasks-deferral.test.ts✅ 6/6pnpm test:projection✅ 65/65 (post-rebase)pnpm test:unit2673 passed; 4 files failed on 5 s timeouts / 150 ms elapsed budgets under load ~120 (event-ipc,mcp-probe-service,dispatcher,native-claude-contract); first three pass in isolation,native-claude-contractstill hits its 5 s cap in isolation on this loaded box — untouched by this PR, left to CI.pnpm test:route-unit34 passed, 1 timeout (lifecycle-replay) → passes in isolationpnpm build && pnpm test:integration:run✅ 938/938pnpm test:mcp-conformance✅ (official runner,2025-11-25, no unexpected failures)Test plan