Repository navigation
Properly export everything #280
Description
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.
Activity
fwextensions commentedon Apr 9, 2025
These weird exports are slowly driving Gemini 2.5 Pro insane:
awhiteside1 commentedon Apr 17, 2025
👋, 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 commentedon Apr 23, 2025
+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 commentedon Apr 24, 2025
@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/mcpMy 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 commentedon Apr 24, 2025
@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 commentedon Apr 24, 2025
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.
Merge pull request modelcontextprotocol#280 from max-stytch/max/disco…
KKonstantinov commentedon Dec 5, 2025
Hi, changing the exports is planned for
v2. See #870 - Closing this until that's a fact.