* Simplify ModelContextProtocol.AspNetCore README
* Add StreamableHttpHandler
* Use "docker info" in CheckIsDockerAvailable
* Call WithHttpTransport in samples, tests and README
* Cleanup test namespaces
* Add CanConnect_WithMcpClient_AfterCustomizingRoute test
* Simplify relative URI handling
* Handle request made directly to the MapMcp route pattern
* Add Messages_FromNewUser_AreRejected test
* Fix README
* Shorten UserIdClaim ValueTuple names
* Remove MaxReconnectAttempts and ReconnectDelay from SseClientTransportOptions
- Add proper AdditionalHeaders support
* Separate ASP.NET Core tests into a distinct project and make the main test project netfx compatible.
* Fix merge conflicts.
* Update tests/ModelContextProtocol.Tests/ModelContextProtocol.Tests.csproj
Co-authored-by: Stephen Halter <halter73@gmail.com>
* Revert "Fix merge conflicts."
This reverts commit 852169b96786bad2144795540fa164e20b4b197e.
* Fix merge conflicts
---------
Co-authored-by: Stephen Halter <halter73@gmail.com>
* Fixes#248 - Add CultureInfo.InvariantCulture to string interpolation for langitude and longitude so the sample works everywhere.
* Update samples/QuickstartWeatherServer/Tools/WeatherTools.cs
Co-authored-by: Stephen Toub <stoub@microsoft.com>
---------
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* Propagate CancellationToken request cancellation to remote endpoint
* Refactor existing tests to have a shared base class
* Add cancellation tests
---------
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* Remove McpServerConfig and have McpClientFactory accept IClientTransport instances directly.
* Address feedback and use lists when representing stdio arguments.
* Use "Name" for transport descriptors and "EndpointName" for MCP clients and servers.
* Update code samples.
* Fix source file naming
* Move notification handler registrations to capabilities
Currently request handlers are set on the capability objects, but notification handlers are set after construction via an AddNotificationHandler method on the IMcpEndpoint interface. This moves handler specification to be at construction as well. This makes it more consistent with request handlers, simplifies the IMcpEndpoint interface to just be about message sending, and avoids a concurrency bug that could occur if someone tried to add a handler while the endpoint was processing notifications.
* Address more feedback and further cleanup
* Reduce dependencies to 8.x versions of packages
When building for netstandard2.0 or net8.0, the ModelContextProtocol library now only depends on 8.x versions of nuget packages, rather than using the newer 9.x versions. The exception to this are packages that don't have 8.x versions.
This also introduces a net9.0 tfm. When building for net9.0, it'll use 9.x versions of packages.
The PR temporarily removes the Microsoft.Extensions.AI.nupkg reference (the Microsoft.Extensions.AI.Abstractions reference is still very much there). The latest Microsoft.Extensions.AI package on nuget has a System.Text.Json 9.x reference, but the next build to be published drops that down to 8.x as well. Once that build is published, the dependency will be added back, and temporary polyfills (in particular TemporaryAIFunctionFactory) will be deleted.
* Fix StdioClientSessionTransport shutdown
StreamClientSessionTransport's ReadMessageAsync method does await CleanupAsync in its finally. CleanupAsync awaits _readTask. _readTask _is_ ReadMessageAsync. So it's waiting for itself to complete, which will then always timeout. We may want to refactor how this works more in the future, but for now, make sure it doesn't wait for itself.
* Fix dangling requests when server unexpectedly shuts down
If the client makes a request to the server and while waiting for the response the server shuts down, the client hangs. Make sure that when the client's message loops ends due to the server's output it's reading from ends, any pending requests are notified.
* Add net9.0 testing
* Avoid docker port conflicts from test suites running concurrently
* Add ModelContextProtocol.AspNetCore
- Remove IServerTransport and HttpListenerSseServerTransport
- Replace HttpListenerSseServerTransport usage in tests with ASP.NET Core.
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
Co-authored-by: Jeff Handley <jeffhandley@users.noreply.github.com>
- This also paves the way for better multi-session support
- We should definitely rethink names for the transport API
- For now, I kept the names similar as possible, so we can
focus on the API shape
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* Overhaul tool handling
- Renames [McpTool{Type}] to [McpServerTool{Type}], in order to distinguish representations of tools on the server from tools on the client.
- Enables [McpServerTool] methods to have arguments injected from DI, as well as a specific set of types from the implementation directly, like IMcpServer.
- Renames WithTools to WithToolsFromAssembly.
- All of the WithToolsXx methods now publish each individual McpServerTool into DI; other code can do so as well. The options setup code gathers all of the tools from DI and combines them into a collection which is then stored in McpServerOptions and used to construct the server.
- The server tools specified via DI as well as manually-provided handlers, using CallToolHandler as a fallback in case the requested tool doesn't exist in the tools collection, and ListToolsHandler augments the information for whatever tools exist.
- The tools are stored in McpServerOptions in a new McpServerToolCollection type, which is a thread-safe container that exposes add/removal notification. Adding/removing tools triggers a change notification that in turn sends a notification to the client about a tools update.
- The ServerOptions are exposed from the server instance.
- Removed cursor-based APIs from McpClientExtensions.
- Changed McpClientExtensions APIs to return `Task<IList<...>` rather than `IAsyncEnumerable<...>`.
I'm sure this will need to evolve further before we're "done", but it's a significant improvement from where we are now. One area I'm not super happy with is the notifying collection; that might work ok for a stdio server, where you can grab the created collection from the server's options and mutate it, but I don't know how well that's going to work for sse servers.
* Make McpServerTool{Collection} extensible
* Fix README.md example
* Add notifications test
* Address feedback
* Make client config optional to McpClientFactory.CreateAsync
Unless you're specifying capabilities (sampling/rooting) or need a specific client name/version, the client information can be inferred from the assembly, simplifying the getting-started experience.
* Cache default options
* Update src/ModelContextProtocol/Client/McpClientFactory.cs
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
---------
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Change type of Tool.InputSchema to be JsonElement
* Add schema validation in the InputSchema property setter.
* Simplify AIFunction tool adapter.
---------
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Add AspNetCoreSseMcpTransport sample
* Fix build errors after rebase
* React to McpServerFactory changes
* Make Utf8JsonWriter non thread static
* Fix test errors caused by not rebasing the HttpLister changes on factory overhaul commit
* Integrate Microsoft.Extensions.AI as a foundational building block
As with logging abstractions coming from M.E.Logging and DI abstractions coming from M.E.DependencyInjection, M.E.AI provides the relevant AI abstractions.
- Adds AsAIFunction and GetAIFunctionsAsync methods for getting functions for tools via a client.
- Uses AIFunctionFactory to implement McpServerBuilderExtensions.WithTools.
- Adds a RequestSamplingAsync overload that accepts ChatMessages/Options.
- Adds an AsSamplingChatClient method that provides an IChatClient usable on the server to request sampling of the client.
- Adds a CreateSamplingHandler method to enable an IChatClient to be easily used to satisfy sampling requests on the client.
- Deprecate McpDotNet.Extensions.AI.
* Address PR feedback
Handlers are now specified before connecting the client/server. Otherwise, race conditions exist. Handlers move into being a part of the McpClientOptions/McpServerOptions, so that they're provided to the factories. Where relevant, the handlers are specified as part of the capability descriptors, so that they go hand in hand.
The factories are no longer stateful. Instead of allocating a factory and then calling a create method on it, you just call a static factory method.
* Improve tool handling
* Rework stuff with new hosting options
* Update readme
* Fix build
* Try run client tests
* Fix build
* Fix issues on linux
* Try to run testserver on linux
* Fix test issue
* Fix code smells
* Server support (stdio)
* TestServer project
* Refactored McpClient class to extract shared endpoint logic (with McpServer) to a base class, McpJsonRpcEndpoint.
* Improved xmldoc comments for protocol types, mirroring specification schema comments.
* Update README.MD
