[jpdefo]

Fixes #3015.

On native Windows, docs:api receives absolute package entry points containing backslashes. TypeDoc treats these as glob escapes, finds none of the eight public packages, and exits with an error. Use package-relative POSIX globs so TypeDoc can resolve them and escape special characters in the checkout directory. Filesystem reads keep their native paths.

Validation on native Windows, against 9bc40e903fde15534ec06ff4c1347d47000dbe16:

• Original pnpm docs:api failed to match all eight packages. The fix generated all eight successfully.
• A fixture using TypeDoc's actual expandPackages helper selected the literal checkout[1] directory with a checkout1 sibling present. Both native and normalized absolute entry-point controls failed. This is a local verification fixture, not an added repository test.
• pnpm build:all, pnpm lint:all, Prettier and git diff --check passed.
• Serial workspace tests with Node 24.18.0 and one worker: 4,121 package tests passed. E2E had 2,693 passed, 141 expected failures and two failing transport:stdio:shutdown-escalation cases. Both failures were reproduced with the original config restored. The recursive command stopped with exit 1, so the integration suite did not complete. Default Node 24.15 worker crashes were also reproduced with the original config.

Only typedoc.config.mjs changes. No runtime, dependency or generated documentation changes. Prepared with Codex assistance and independently reviewed by four Luna agents and one Sol agent after the final change.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 373f168

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]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@3016

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@3016

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@3016

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@3016

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@3016

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@3016

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@3016

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@3016

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@3016

commit: 373f168

[karaaslanz]

I reviewed the exact docs-only head 0600a7d1a0d6d0cabe564f1ab2114bd0eca6a72b, comparing the pinned typedoc.config.mjs blobs from base 9bc40e903fde15534ec06ff4c1347d47000dbe16 (blob 99c74f4e6565bf7b84ff4816f66d72685c20a626) and this PR (blob 4932484be47b2cba321b8cf876b1fc4ceb10bd7e).

I extracted and executed the actual entryPoints = publicPackages.map(...) expression from each version, using Node's native path.win32 functions and three Windows checkout fixtures:

• C:\Dev\MCP SDK\packages\client -> patched packages/client
• C:\Dev\checkout[1]\packages\server -> patched packages/server
• C:\Dev\MCP SDK\packages\core-internal -> patched packages/core-internal

The unmodified base returns absolute backslash-containing Windows paths in all three cases, while the patched expression returns the expected relative, forward-slash package entries. 6/6 exact-source path assertions passed. This aligns with the reported Windows glob-path failure and removes the checkout prefix, including any special characters in the checkout folder, from TypeDoc's entry glob.

Scope: This is an independent pinned-source path-generation check only, not a full pnpm docs:api/TypeDoc run, and it does not independently prove TypeDoc's package-glob resolution or every Windows filesystem edge case. The author's PR description reports full Windows TypeDoc validation. I found no issue in the narrow transformation tested here and made no repository edits.