') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); test(e2e): audit transport-restricted requirements for the entry arms; admit two and harden entryModern by felixweinberger · Pull Request #2312 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

test(e2e): audit transport-restricted requirements for the entry arms; admit two and harden entryModern - #2312

Merged
felixweinberger merged 2 commits into
v2-2026-07-28from
fweinberger/e2e-arm-applicability
Jun 16, 2026
Merged

test(e2e): audit transport-restricted requirements for the entry arms; admit two and harden entryModern#2312
felixweinberger merged 2 commits into
v2-2026-07-28from
fweinberger/e2e-arm-applicability

Conversation

@felixweinberger

@felixweinbergerfelixweinberger commented Jun 16, 2026•
edited
Loading

Copy link
Copy Markdown
Contributor

Audits every transport-restricted requirement in the e2e manifest for applicability to the createMcpHandler entry arms, admits the two whose bodies the per-request entry can already serve, and hardens the entryModern arm against negotiation/envelope drift.

Motivation and Context

The entry arms added in #2309 opt in every requirement without an explicit transports restriction; the ~240 rows that carry one were authored before the entry existed and never reach the arms. This pass reviews each of them so that nothing is skipped silently: requirements the per-request entry can serve today are admitted, and the rest are confirmed as blocked on missing entry features (server→client requests, sessions/standalone streams) or as genuinely transport-specific.

  • Two requirements join the entry arms (+4 cells, all green): flow:tool-result:resource-link-follow and custom-methods:notification-handler. Both bodies need only request-scoped delivery, so the per-request entry serves them unmodified on both eras; their notes explain the inclusion. No scenario body was changed and no knownFailure or exclusion was added.
  • The rest stay restricted on purpose. Server→client request flows (sampling, elicitation, roots), subscription/list-changed/standalone-stream behaviors, session lifecycle and resumability, and persistent-instance state cannot be expressed on a per-request entry yet; transport-class internals, framework adapters, and stdio/SSE-specific mechanics never will be. The OAuth/auth scenarios stay restricted for a different reason: their bodies host their own servers and auth stacks, so labelling them with an entry arm would not exercise the entry — authenticated serving through createMcpHandler needs dedicated entry-side scenarios, which this review calls out as follow-up coverage alongside the other generic HTTP-mechanics behaviors that deserve dedicated entry-side cells later (several already have them).
  • entryModern arm hardening. The arm now asserts immediately after connect that the connection actually negotiated 2026-07-28, so a broken negotiation pin produces one attributable arm-level failure instead of hundreds of downstream ones; and the per-request envelope shim now captures from the latest enveloped message rather than the first, so a renegotiated connection could not keep claiming a stale version.

How Has This Been Tested?

Full e2e matrix before/after on the same machine: 2536 passed / 205 expected-fail / 2741 cells → 2540 / 205 / 2745, zero unexpected failures in both runs. Package typecheck and lint for the e2e workspace are green. No package source, examples, or conformance changes.

Breaking Changes

None — test-only.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Test/coverage change (no runtime behavior change)

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

One candidate that looked admissible analytically — logging emitted via the request context (ctx.mcpReq.log) while the handler is still running — stays restricted, and the reason is sharper than a missing delivery channel: those notifications are emitted without a relatedRequestId, and the per-request transport drops messages that are not related to the single in-flight request, so handler-context logs are never delivered when serving through createMcpHandler. Request-related notifications and progress do ride the in-flight exchange (which is why those cells pass on the entry arms). Whether handler-context logging should be emitted as request-related on per-request serving is left as an explicit follow-up rather than changed here.

@felixweinberger
test(e2e): harden the entryModern arm against negotiation and envelop…
02b0269
…e drift
- assert right after connect that an entryModern connection actually negotiated
2026-07-28, so a broken negotiation pin fails as one attributable arm-level
error instead of hundreds of downstream assertion failures
- attachModernEnvelope now captures the envelope from the latest enveloped
message (plain assignment instead of first-capture), so a renegotiated
connection would not keep stamping a stale protocol-version claim
@felixweinberger
test(e2e): run two transport-restricted requirements through the entr…
e843eab
…y arms
flow:tool-result:resource-link-follow and custom-methods:notification-handler
were restricted to the stateful transports before the createMcpHandler entry
arms existed, but their bodies only need request-scoped delivery (plain
client-to-server requests, with related notifications observed after the call
completes), so the per-request entry serves them unmodified. Add the
entryStateless/entryModern arms to their transports and explain the inclusion
in their notes (+4 cells, all passing).
The remaining transport-restricted requirements were reviewed and stay
restricted: they need a server-to-client back-channel, a persistent session or
standalone stream, or assert genuinely transport-specific behavior.
@felixweinberger
felixweinberger requested a review from a team as a code ownerJune 16, 2026 19:36
@changeset-bot

changeset-botBot commented Jun 16, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: e843eab

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@pkg-pr-new

pkg-pr-newBot commented Jun 16, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@2312

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/codemod@2312

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@2312

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server-legacy@2312

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@2312

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/fastify@2312

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@2312

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@2312

commit: e843eab

@felixweinberger
felixweinberger merged commit a716481 into v2-2026-07-28Jun 16, 2026
14 checks passed
@felixweinberger
felixweinberger deleted the fweinberger/e2e-arm-applicability branch June 16, 2026 22:05
felixweinberger added a commit that referenced this pull request Jun 24, 2026
@felixweinberger
test(e2e): audit transport-restricted requirements for the entry arms…
37b1d30
…; admit two and harden entryModern (#2312)
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@felixweinberger