Fix: Barrel file exports

[KKonstantinov]

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import{StreamableHTTPServerTransport}from'@modelcontextprotocol/sdk/server/streamableHttp.js';import{McpServer}from'@modelcontextprotocol/sdk/server/mcp.js';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

• @modelcontextprotocol/sdk/server
• @modelcontextprotocol/sdk/client
• @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import{StreamableHTTPServerTransport,McpServer}from'@modelcontextprotocol/sdk/server';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

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

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

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

[KKonstantinov]

@cliffhall@ihrpr this is an extension to #851

[cliffhall]

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

[ihrpr]

Let's include it in V2

[cliffhall]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

[ihrpr]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

[joelachance]

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[KKonstantinov]

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[joelachance]

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

[KKonstantinov]

Due to prettier's merge, there's conflicts here which I'll resolve.

But there's another decision point here to make.

In package.json, we've got:

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

Which is a non-existent file. So that has to be removed. Since exporting from /server and /client is already a fact, we couldn't go back to exporting just from @modelcontextprotocol/sdk because that would constitute a huge breaking change.

We also mustn't export the same files from both @modelcontextprotocol/sdk and /client or /server (or /shared), because that will end up being super confusing - stuff should get exported in an expected, standardized way and not duplicate exports.

Thus our option for now if we dont want breaking changes is to just remove the main export.

[KKonstantinov]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

[cliffhall]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

Could you make this a draft for now?

[KKonstantinov]

Now up to date with main.

Have further removed the import that is breaking things for various people (and does not exist).

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

I could see this being raised in more issues, maybe we could plan on when to release it? It does constitute breaking changes, so it'd have to be in a major version, v2 or else.

[pkg-pr-new]

Open in StackBlitz

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

commit: 5957da3

[cliffhall]

Good catch. This didn't belong here :)

[felixweinberger]

Going through old PRs right now if anything can be cleaned up.

@KKonstantinov I think we can close this out now that we landed your monorepo refactor in #1279 which solves this problem right?

Feel free to reopen if you still wanted to land a version of this in v1.x though!

[KKonstantinov]

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import{StreamableHTTPServerTransport}from'@modelcontextprotocol/sdk/server/streamableHttp.js';import{McpServer}from'@modelcontextprotocol/sdk/server/mcp.js';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

• @modelcontextprotocol/sdk/server
• @modelcontextprotocol/sdk/client
• @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import{StreamableHTTPServerTransport,McpServer}from'@modelcontextprotocol/sdk/server';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

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

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

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

[KKonstantinov]

@cliffhall@ihrpr this is an extension to #851

[cliffhall]

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

[ihrpr]

Let's include it in V2

[cliffhall]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

[ihrpr]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

[joelachance]

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[KKonstantinov]

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[joelachance]

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

[KKonstantinov]

Due to prettier's merge, there's conflicts here which I'll resolve.

But there's another decision point here to make.

In package.json, we've got:

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

Which is a non-existent file. So that has to be removed. Since exporting from /server and /client is already a fact, we couldn't go back to exporting just from @modelcontextprotocol/sdk because that would constitute a huge breaking change.

We also mustn't export the same files from both @modelcontextprotocol/sdk and /client or /server (or /shared), because that will end up being super confusing - stuff should get exported in an expected, standardized way and not duplicate exports.

Thus our option for now if we dont want breaking changes is to just remove the main export.

[KKonstantinov]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

[cliffhall]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

Could you make this a draft for now?

[KKonstantinov]

Now up to date with main.

Have further removed the import that is breaking things for various people (and does not exist).

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

I could see this being raised in more issues, maybe we could plan on when to release it? It does constitute breaking changes, so it'd have to be in a major version, v2 or else.

[pkg-pr-new]

Open in StackBlitz

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

commit: 5957da3

[cliffhall]

Good catch. This didn't belong here :)

[felixweinberger]

Going through old PRs right now if anything can be cleaned up.

@KKonstantinov I think we can close this out now that we landed your monorepo refactor in #1279 which solves this problem right?

Feel free to reopen if you still wanted to land a version of this in v1.x though!

[KKonstantinov]

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import{StreamableHTTPServerTransport}from'@modelcontextprotocol/sdk/server/streamableHttp.js';import{McpServer}from'@modelcontextprotocol/sdk/server/mcp.js';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

• @modelcontextprotocol/sdk/server
• @modelcontextprotocol/sdk/client
• @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import{StreamableHTTPServerTransport,McpServer}from'@modelcontextprotocol/sdk/server';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

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

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

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

[KKonstantinov]

@cliffhall@ihrpr this is an extension to #851

[cliffhall]

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

[ihrpr]

Let's include it in V2

[cliffhall]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

[ihrpr]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

[joelachance]

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[KKonstantinov]

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[joelachance]

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

[KKonstantinov]

Due to prettier's merge, there's conflicts here which I'll resolve.

But there's another decision point here to make.

In package.json, we've got:

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

Which is a non-existent file. So that has to be removed. Since exporting from /server and /client is already a fact, we couldn't go back to exporting just from @modelcontextprotocol/sdk because that would constitute a huge breaking change.

We also mustn't export the same files from both @modelcontextprotocol/sdk and /client or /server (or /shared), because that will end up being super confusing - stuff should get exported in an expected, standardized way and not duplicate exports.

Thus our option for now if we dont want breaking changes is to just remove the main export.

[KKonstantinov]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

[cliffhall]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

Could you make this a draft for now?

[KKonstantinov]

Now up to date with main.

Have further removed the import that is breaking things for various people (and does not exist).

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

I could see this being raised in more issues, maybe we could plan on when to release it? It does constitute breaking changes, so it'd have to be in a major version, v2 or else.

[pkg-pr-new]

Open in StackBlitz

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

commit: 5957da3

[cliffhall]

Good catch. This didn't belong here :)

[felixweinberger]

Going through old PRs right now if anything can be cleaned up.

@KKonstantinov I think we can close this out now that we landed your monorepo refactor in #1279 which solves this problem right?

Feel free to reopen if you still wanted to land a version of this in v1.x though!

[KKonstantinov]

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import{StreamableHTTPServerTransport}from'@modelcontextprotocol/sdk/server/streamableHttp.js';import{McpServer}from'@modelcontextprotocol/sdk/server/mcp.js';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

• @modelcontextprotocol/sdk/server
• @modelcontextprotocol/sdk/client
• @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import{StreamableHTTPServerTransport,McpServer}from'@modelcontextprotocol/sdk/server';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

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

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

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

[KKonstantinov]

@cliffhall@ihrpr this is an extension to #851

[cliffhall]

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

[ihrpr]

Let's include it in V2

[cliffhall]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

[ihrpr]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

[joelachance]

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[KKonstantinov]

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[joelachance]

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

[KKonstantinov]

Due to prettier's merge, there's conflicts here which I'll resolve.

But there's another decision point here to make.

In package.json, we've got:

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

Which is a non-existent file. So that has to be removed. Since exporting from /server and /client is already a fact, we couldn't go back to exporting just from @modelcontextprotocol/sdk because that would constitute a huge breaking change.

We also mustn't export the same files from both @modelcontextprotocol/sdk and /client or /server (or /shared), because that will end up being super confusing - stuff should get exported in an expected, standardized way and not duplicate exports.

Thus our option for now if we dont want breaking changes is to just remove the main export.

[KKonstantinov]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

[cliffhall]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

Could you make this a draft for now?

[KKonstantinov]

Now up to date with main.

Have further removed the import that is breaking things for various people (and does not exist).

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

I could see this being raised in more issues, maybe we could plan on when to release it? It does constitute breaking changes, so it'd have to be in a major version, v2 or else.

[pkg-pr-new]

Open in StackBlitz

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

commit: 5957da3

[cliffhall]

Good catch. This didn't belong here :)

[felixweinberger]

Going through old PRs right now if anything can be cleaned up.

@KKonstantinov I think we can close this out now that we landed your monorepo refactor in #1279 which solves this problem right?

Feel free to reopen if you still wanted to land a version of this in v1.x though!

[KKonstantinov]

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import{StreamableHTTPServerTransport}from'@modelcontextprotocol/sdk/server/streamableHttp.js';import{McpServer}from'@modelcontextprotocol/sdk/server/mcp.js';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

• @modelcontextprotocol/sdk/server
• @modelcontextprotocol/sdk/client
• @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import{StreamableHTTPServerTransport,McpServer}from'@modelcontextprotocol/sdk/server';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

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

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

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

[KKonstantinov]

@cliffhall@ihrpr this is an extension to #851

[cliffhall]

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

[ihrpr]

Let's include it in V2

[cliffhall]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

[ihrpr]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

[joelachance]

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[KKonstantinov]

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[joelachance]

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

[KKonstantinov]

Due to prettier's merge, there's conflicts here which I'll resolve.

But there's another decision point here to make.

In package.json, we've got:

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

Which is a non-existent file. So that has to be removed. Since exporting from /server and /client is already a fact, we couldn't go back to exporting just from @modelcontextprotocol/sdk because that would constitute a huge breaking change.

We also mustn't export the same files from both @modelcontextprotocol/sdk and /client or /server (or /shared), because that will end up being super confusing - stuff should get exported in an expected, standardized way and not duplicate exports.

Thus our option for now if we dont want breaking changes is to just remove the main export.

[KKonstantinov]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

[cliffhall]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

Could you make this a draft for now?

[KKonstantinov]

Now up to date with main.

Have further removed the import that is breaking things for various people (and does not exist).

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

I could see this being raised in more issues, maybe we could plan on when to release it? It does constitute breaking changes, so it'd have to be in a major version, v2 or else.

[pkg-pr-new]

Open in StackBlitz

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

commit: 5957da3

[cliffhall]

Good catch. This didn't belong here :)

[felixweinberger]

Going through old PRs right now if anything can be cleaned up.

@KKonstantinov I think we can close this out now that we landed your monorepo refactor in #1279 which solves this problem right?

Feel free to reopen if you still wanted to land a version of this in v1.x though!

[KKonstantinov]

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import{StreamableHTTPServerTransport}from'@modelcontextprotocol/sdk/server/streamableHttp.js';import{McpServer}from'@modelcontextprotocol/sdk/server/mcp.js';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

• @modelcontextprotocol/sdk/server
• @modelcontextprotocol/sdk/client
• @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import{StreamableHTTPServerTransport,McpServer}from'@modelcontextprotocol/sdk/server';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

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

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

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

[KKonstantinov]

@cliffhall@ihrpr this is an extension to #851

[cliffhall]

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

[ihrpr]

Let's include it in V2

[cliffhall]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

[ihrpr]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

[joelachance]

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[KKonstantinov]

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[joelachance]

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

[KKonstantinov]

Due to prettier's merge, there's conflicts here which I'll resolve.

But there's another decision point here to make.

In package.json, we've got:

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

Which is a non-existent file. So that has to be removed. Since exporting from /server and /client is already a fact, we couldn't go back to exporting just from @modelcontextprotocol/sdk because that would constitute a huge breaking change.

We also mustn't export the same files from both @modelcontextprotocol/sdk and /client or /server (or /shared), because that will end up being super confusing - stuff should get exported in an expected, standardized way and not duplicate exports.

Thus our option for now if we dont want breaking changes is to just remove the main export.

[KKonstantinov]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

[cliffhall]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

Could you make this a draft for now?

[KKonstantinov]

Now up to date with main.

Have further removed the import that is breaking things for various people (and does not exist).

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

I could see this being raised in more issues, maybe we could plan on when to release it? It does constitute breaking changes, so it'd have to be in a major version, v2 or else.

[pkg-pr-new]

Open in StackBlitz

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

commit: 5957da3

[cliffhall]

Good catch. This didn't belong here :)

[felixweinberger]

Going through old PRs right now if anything can be cleaned up.

@KKonstantinov I think we can close this out now that we landed your monorepo refactor in #1279 which solves this problem right?

Feel free to reopen if you still wanted to land a version of this in v1.x though!

[KKonstantinov]

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import{StreamableHTTPServerTransport}from'@modelcontextprotocol/sdk/server/streamableHttp.js';import{McpServer}from'@modelcontextprotocol/sdk/server/mcp.js';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

• @modelcontextprotocol/sdk/server
• @modelcontextprotocol/sdk/client
• @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import{StreamableHTTPServerTransport,McpServer}from'@modelcontextprotocol/sdk/server';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

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

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

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

[KKonstantinov]

@cliffhall@ihrpr this is an extension to #851

[cliffhall]

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

[ihrpr]

Let's include it in V2

[cliffhall]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

[ihrpr]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

[joelachance]

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[KKonstantinov]

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[joelachance]

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

[KKonstantinov]

Due to prettier's merge, there's conflicts here which I'll resolve.

But there's another decision point here to make.

In package.json, we've got:

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

Which is a non-existent file. So that has to be removed. Since exporting from /server and /client is already a fact, we couldn't go back to exporting just from @modelcontextprotocol/sdk because that would constitute a huge breaking change.

We also mustn't export the same files from both @modelcontextprotocol/sdk and /client or /server (or /shared), because that will end up being super confusing - stuff should get exported in an expected, standardized way and not duplicate exports.

Thus our option for now if we dont want breaking changes is to just remove the main export.

[KKonstantinov]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

[cliffhall]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

Could you make this a draft for now?

[KKonstantinov]

Now up to date with main.

Have further removed the import that is breaking things for various people (and does not exist).

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

I could see this being raised in more issues, maybe we could plan on when to release it? It does constitute breaking changes, so it'd have to be in a major version, v2 or else.

[pkg-pr-new]

Open in StackBlitz

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

commit: 5957da3

[cliffhall]

Good catch. This didn't belong here :)

[felixweinberger]

Going through old PRs right now if anything can be cleaned up.

@KKonstantinov I think we can close this out now that we landed your monorepo refactor in #1279 which solves this problem right?

Feel free to reopen if you still wanted to land a version of this in v1.x though!

[KKonstantinov]

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import{StreamableHTTPServerTransport}from'@modelcontextprotocol/sdk/server/streamableHttp.js';import{McpServer}from'@modelcontextprotocol/sdk/server/mcp.js';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

• @modelcontextprotocol/sdk/server
• @modelcontextprotocol/sdk/client
• @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import{StreamableHTTPServerTransport,McpServer}from'@modelcontextprotocol/sdk/server';import{isInitializeRequest,LoggingLevelSchema,SetLevelRequestSchema}from'@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

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

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

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

[KKonstantinov]

@cliffhall@ihrpr this is an extension to #851

[cliffhall]

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

[ihrpr]

Let's include it in V2

[cliffhall]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

[ihrpr]

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

[joelachance]

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[KKonstantinov]

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

[joelachance]

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

[KKonstantinov]

Due to prettier's merge, there's conflicts here which I'll resolve.

But there's another decision point here to make.

In package.json, we've got:

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

Which is a non-existent file. So that has to be removed. Since exporting from /server and /client is already a fact, we couldn't go back to exporting just from @modelcontextprotocol/sdk because that would constitute a huge breaking change.

We also mustn't export the same files from both @modelcontextprotocol/sdk and /client or /server (or /shared), because that will end up being super confusing - stuff should get exported in an expected, standardized way and not duplicate exports.

Thus our option for now if we dont want breaking changes is to just remove the main export.

[KKonstantinov]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

[cliffhall]

This has accumulated conflicts over time.

cc @ihrpr when we are close to doing the v2 milestone, I'll resolve all of them.

Could you make this a draft for now?

[KKonstantinov]

Now up to date with main.

Have further removed the import that is breaking things for various people (and does not exist).

".": {
"import": "./dist/esm/index.js",
"require": "./dist/cjs/index.js"
}

I could see this being raised in more issues, maybe we could plan on when to release it? It does constitute breaking changes, so it'd have to be in a major version, v2 or else.

[pkg-pr-new]

Open in StackBlitz

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

commit: 5957da3

[cliffhall]

Good catch. This didn't belong here :)

[felixweinberger]

Going through old PRs right now if anything can be cleaned up.

@KKonstantinov I think we can close this out now that we landed your monorepo refactor in #1279 which solves this problem right?

Feel free to reopen if you still wanted to land a version of this in v1.x though!