feat: use informative user agent in HTTP requests

[LucaButBoring]

Configures a descriptive user agent in all HTTP requests.

Example (Node): my-mcp-sdk/1.17.2 os/darwin#24.5.0 lang/js md/nodejs#22.13.1

Example (Browser): mcp-sdk-ts/1.17.2 os/macOS#10.15.7 lang/js

• The browser user agent looks slightly different due to the method of acquiring the platform being different than in Node. Refer to userAgent.test.ts for details.

Motivation and Context

Makes debugging client/server incompatibilities easier.

How Has This Been Tested?

Unit tests.

Breaking Changes

No breaking changes.

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

Reference implementation for modelcontextprotocol/modelcontextprotocol#1329

[tkaria]

I'm curious why we wouldn't extend the UA string further to include the model being used on the client. Wouldn't this enable servers to tailor responses to different models of varying capabilities?

[LucaButBoring]

I'm curious why we wouldn't extend the UA string further to include the model being used on the client. Wouldn't this enable servers to tailor responses to different models of varying capabilities?

I think supporting overriding the UA is a good idea (I'll add that), so that applications can provide this if they want to, but I think there are two problems with this suggestion beyond that:

1. The client SDK cannot know the model - there may not even necessarily be one, in the case of e.g. the MCP inspector.
2. It would not be a very good idea to use the UA to change tool behavior, as UAs are not reliable and may not be provided at all (an application may strip them entirely for privacy reasons, or provide them in a different format if it's feeling quirky, etc.). As a tool dev, I might get bug reports related to response quality that I would now need to isolate to both the actual model itself and to how the application chose (or did not choose) to report the model identifier to the MCP server.

I think model capability-sharing is useful, like sharing if a model is multimodal or not, but I don't think the UA is the right place for communicating that information. It should be proposed as a separate extension to the existing MCP capability-sharing during initialization, I think.

[LucaButBoring]

Updated this PR and added support for overriding the UserAgentProvider.

[pkg-pr-new]

Open in StackBlitz

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

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

commit: 4801c2e

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4801c2e

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