* Set up a root artifacts folder for all build/test/pack output
Update CI TestResults folder
* Update package Authors and Copyright
* Lower-case extension on README.md
* Move package props to src folder. Use Version prefix and suffix props.
* Set up package publishing for daily, manual, and release builds
* Only run publishing jobs to the modelcontextprotocol/csharp-sdk repo
* Fix condition on docs workflow
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update preview wording in README to apply to the package too
* Verify packaging succeeds in the CI workflow
* Allow a version suffix override in release workflow.
* De-dupe the README between the repo and the NuGet package
* New CI work
* Do not reuse the CI workflow for releases so we can build without tests.
* Add a release process doc
* Fix bug in publishing; needs checkout step. Update comment for publish.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* List tools from DI once
- Follow best practice to not mutate options outside of IConfigureOptions
- Long-term, we should move the repeated work from SetToolsHandler into
an IPostConfigureOptions service or IMcpServerConnectionFactory
* Add Can_Create_Multiple_Servers_From_Options_And_List_Registered_Tools
* Flip stdin and stdout in StreamClientTransport
* s/McpToolType/McpServerToolType
* Clarify stdin and stdout refers to server process in StreamClientTransport
* fixup
* 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
* Add acknowledgements to README
* Apply suggestions from PR review.
Co-authored-by: Stephen Toub <stoub@microsoft.com>
---------
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* 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>
* 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
- Modified `GetCommand` to return OS-specific commands and changed return type to `string?`.
- Improved `InitializeCommand` for better command initialization and logging.
- Cleaned up using directives in `Log.cs` and `SseClientTransport.cs`.
- Updated `CreateNoWindow` property in `StdioClientTransport` to be OS-dependent.
- Bumped version number in `mcpdotnet.csproj` to 1.0.1.1.
* 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
