Properly export everything

[Moe03]

Is your feature request related to a problem? Please describe.
Why don't we do
import { McpServer, ResourceTemplate } from "@modelcontextprotocol/sdk";
import { StdioServerTransport } from "@modelcontextprotocol/sdk";

Instead of ?
import { McpServer, ResourceTemplate } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

Describe the solution you'd like
we just properly export the classes, types from index.d.ts

Describe alternatives you've considered
Current setup works but is not easily identifiable by LLMs causing a lot of easy to fix issues, also this is the norm to just export everything properly.

[fwextensions]

These weird exports are slowly driving Gemini 2.5 Pro insane:

It appears the TS2307: Cannot find module '@modelcontextprotocol/sdk' error is quite persistent, even after trying different import paths. This often points to an issue with the installation itself (corrupted node_modules or cache) or potentially with the SDK package's type definitions.

[awhiteside1]

👋, chiming in cause it bugged me enough while using the SDK today.

It also causes problems with the stricter import rules of Deno and Pnpm. Combined with non-bundler import extensions it's not nice for IDE Autocomplete or LLM.

Here's how to do exports in modern TS, which has changed like every few months recently it feels like 😭

https://www.nullfox.com/multiple-exports-typescript-package-types

Side note: If the separation is because clients need to be able to run in a browser, I'd suggest having two packages published from the same workspace, which share common code via private packages or exposing a sub export properly and importing one from the other. If most of the shared code is the protocol (types, commands, schemas), that seems like a natural shared dependency.

[alexander-zuev]

+1

I may be wrong but I don't see any types exported whatsoever - I don't understand how is this possible and I've checked that this is not an IDE issue

[awhiteside1]

+1

I may be wrong but I don't see any types exported whatsoever - I don't understand how is this possible and I've checked that this is not an IDE issue

@alexander-zuev, they're in there, you can confirm by expanding the tarball from NPM
npm view @modelcontextprotocol/sdk dist.tarball .

(one liner to expand it in tmp)
mkdir -p /tmp/mcp && curl -sSL "$(npm view @modelcontextprotocol/sdk dist.tarball)" | tar -xzvf - -C /tmp/mcp

My guess would be your files scopes in IDEA/Webstorm are setup to hide compiled js files. If you right click and open in finder I'd bet you'd see them.

[alexander-zuev]

@awhiteside1 thanks a lot for a reply, didn't expect it honestly - I was going mad about it because it's suuuper hard to work without being able to import types from the SDK

I appreciate this might be my IDEA's issue but I am at a loss why doesn't it install with the tarballs?

Man you are a savior! OK They are there, but then how do I fix this in PyCharm?

I am left with "no declaration to go to" error

I'll try to chatgpt the hell out of it as this is like flying blind

UPD: 🤦‍♂️ Fixed by removing dist from being an ignored file type. Oh my

[awhiteside1]

Glad it worked out.

In case it helps, over the years I've found that the language specific IDES (pycharm/webstorm/etc) tend to be really bad at polyglot projects. Since they often allow conventions to 'just work' at the expense of explicitness / obviousness.

Whenever I have a multi language project I always use IntelliJ IDEA - even if I'm not actually doing anything with the JVM - since jetbrains releases python/js/go/etc plugins that seem to work together better. Because the project structure of IDEA projects are more explicit (thanks mvn), and IDEA is the everything IDE, I've had decent luck with organizing projects with very different module toolchains.

That being said, given the state of FFIs, WASM, native typescript support/embedded runtimes, 90% of the time you should be able to choose one or the other, and drastically reduce the surface area of the secondary, and expose individual functions with generated interfaces. That way you can completely script away and not rely on the IDE magic for the secondary language. I realize this is kinda hand wavy - it’s early days for these approaches. But worth a google.

Happy to help, we used to waste so much dev time in IDE shenanigans it was painful. Enforcing settings template was a surprising requirement to scale.

[KKonstantinov]

Hi, changing the exports is planned for v2. See #870 - Closing this until that's a fact.