fix(sequentialthinking): read server version from package.json

[KarlLeen]

Fixes #4575

Read serverInfo.version from package.json at runtime instead of hardcoding "0.2.0".

Published @modelcontextprotocol/server-sequential-thinking@2026.7.4 still ships dist/index.js with version: "0.2.0" while its package.json is "2026.7.4". Same class of bug as #4406 for memory; related to #360.

Changes

• Add version.ts with resolvePackageVersion() (source + dist/ layouts)
• Wire McpServer to SERVER_VERSION
• Tests: not "0.2.0", optional dist resolve, stdio initialize smoke via SDK client

How Has This Been Tested?

• cd src/sequentialthinking && npm run build && npm test → 17 passed
• rm -rf dist && npm test → 15 passed, 2 skipped
• Stdio smoke: SDK Client + StdioClientTransport against dist/index.js; getServerVersion().version matches package.json

Note

Aligns serverInfo with package.json (in-tree 0.6.2). CalVer on the next publish follows whatever release writes into package.json (see #3870).

Server Details

• Server: sequentialthinking
• Changes to: serverInfo version reporting

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have tested this with an LLM client (stdio initialize smoke)
• My code follows the repository's style guidelines
• New and existing tests pass locally

[Medsaad]

Thanks for picking this up, runtime resolution is the right call, and I think the case for it is even stronger than the PR states.

scripts/release.py:70-76 (NpmPackage.update_version) rewrites package.json["version"] to a date-based version from gen_version() at release time. So a version literal committed in TS source is stale by construction .. it is never the version that actually ships. That means this isn't a missed bump in sequentialthinking, it's actually systemic, and it applies to every TS server:

• sequentialthinking: in codebase > 0.2.0 but in package.json 0.6.2
• filesystem: in codebase > 0.2.0 but in package.json 0.6.3
• memory: 0.6.3 manually updated in codebase
• everything: 2.0.0 same in both codebase and package.json

memory and everything look fine today but drift as soon as a release stamps their manifests.

I've put together a branch applying this across all four servers, with tests for the fallback and error-propagation paths (40 new tests, none skipped). Happy to go whichever way is most useful, either I open it as a follow-up (only with the remaining 3 servers) once this lands, or you fold these changes in here. Your call, and I don't want to step on your PR.

[KarlLeen]

Thanks @Medsaad , great catch on the release.py CalVer rewrite; that makes the systemic case clear.

I'd prefer to keep this PR focused on sequentialthinking (#4575). Once it lands, a follow-up that applies the same pattern to filesystem / memory / everything (with your extra fallback/error-path tests) sounds ideal. Happy to review that PR.

If maintainers would rather one combined change, I'm also fine folding your branch into this one, just say the word.

[Medsaad]

Sounds good! I've created a draft PR that I'll open once this is merged.