* Use lowercase host in resource URI template derivation.
* Address feedback
* Add casing testing for non-templated resource lookups.
* Fix uri primitive lookup
* Use a hardcoded mcp hostname in derived resource template URIs and ensure built-in resources work with the VS Code client.
* Address feedback
* Fix equality comparison
* Use dedicated type for resource collections.
* Update content according to latest spec
* Add Title to a bunch of types
* Add _meta to lots of types
* Address feedback, more cleanup, fix NAOT test failure
- It allows a single MCP session spanning multiple requests
to be handled by different servers without sharing state
- It does require the servers share data protection keys, but this
is standard for ASP.NET Core cookies and antiforgery as well
- It immediately throws for unsupported operations like sampling
* Add McpServer/ClientResource{Template} and friends
This PR copies the same design used by tools and prompts to add McpServerResource, McpServerResourceAttribute, McpServerResourceTypeAttribute, McpClientResource, and then all of those for ResourceTemplate as well.
Unlike the others, [McpServerResource] is permitted not only on methods but also on properties. This convenience is afforded because such resources aren't parameterized, and thus can be easily modeled as properties, likely auto-props, e.g.
```C#
[McpServerResource]
public static BlobResourceContents MyAmazingData { get; } = Create();
```
Details about resources can be encoded into the attributes or provided via McpServerResource{Template}.Create methods. If not URI is explicitly defined, one is derived from the member name and arguments. For templates, this means manufacturing a URI template that includes variables for all non-DI parameters.
This also fixes a few issues discovered along the way:
- McpClientExtensions are updated to use `ValueTask<T>` instead of `Task<T>` where relevant.
- McpServerPrompt was missing handling for progress notifications; that's been rectified. It was also missing configuring the description on the ProtocolPrompt.
- Renamed IMcpServerPrimitive.Name to Id. For resources, names aren't unique.
- After going back and forth, updated McpServer to not fail for missing handlers and to instead register default handlers. It simplifies the implementation and makes it more consistent.
- Added a bunch of primitive types into the McpJsonUtilities JSON source generator context so that such primitives are usable with tools/prompts/resources without folks being required to add them into their own context for Native AOT. I think we should consider pushing this down to AIJsonUtilities, instead, and that will then flow up to McpJsonUtilities automatically.
* Address feedback
* Add SchemaCreateOptions in McpServerToolCreateOptions
* Use TransformSchemaNode for SchemaCreateOptions testing
* Add SchemaCreateOptions in McpServerPromptCreateOptions also
- Changes IJsonRpcMessage to an abstract base class so RelatedTransport will always be available
- Streamable HTTP supports multiple concurrent HTTP request with their own indpendent SSE response streams
- RelatedTransport indicates the source or destination of the JsonRpcMessage
- Changes the default RequestId to a JSON number for better compatibility with MCP servers in the wild
* 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>
* Add route pattern parameter to MapMcp
* Add configureOptionsAsync
* Use Kestrel for all in-memory HTTP tests
* Use ApplicationStopping token for SSE responses
* Use RegisterNotificationHandler in MapMcp tests
* Work around SocketsHttpHandler bug where it doesn't call DispseAsync on the stream returned by the ConnectCallback
- We still allow notification handlers to be configured pre-creation, eliminating any race conditions that may result from missed notifications. But now we also allow for post-creation notification handler registration.
- Handlers may now also be removed. This permits temporary registrations that may be created in a scoped manner.
- Registration handling is thread-safe.
- Handlers are now cancelable.
- Exceptions from notification handlers trigger all normal exception handling in the dispatch pipeline.
This also:
- Adds a WithStreamServerTransport as a counterpart to WithStdioServerTransport. The latter was used in several tests in a hacky way, and that's now simplified via the former's existence.
* 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
* Allow user-defined JsonSerializerOptions for user-defined and inputs and hardcode everything else to the source generator.
* Add validation for user-defined JsonSerializerOptions.
* Remove out of date comment.
* Address feedback and add tests
* Move WriteJsonRpcMessageToBuffer to method
* Fix indentation in McpClient
* Make supposedly unreachable code less reachable
* Guard against multiple RunAsync calls
* Move RunAsync inside of Try in MapMcp
- We were adding tools/prompts from the collections on every request. If multiple requests came in with different cursors, we'd re-add the same tools each time.
- We were defeating the purpose of pagination by doing all of the aggregation in the server. If a custom handler returns a paginated result, we should instead propagate that back to the client, who can choose to get more results when needed.
* 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>
* Improve progress reporting
- Enable injecting an `IProgress<>` into a tool call to report progress when the client has supplied a progress token
- Add a custom type for ProgressToken and ProgressNotification to map to the schema
- Simplify RequestId to match ProgressToken's shape
- Serialize StdioClientTransport's SendMessageAsync implementation
- Add strongly-typed names for all request methods
- Change all request IDs created by McpJsonRpcEndpoint to include a guid for that endpoint
* Address PR feedback
* Supporting resource templates with read resource callback
Fixes#123
* Aligning the resource data structures with the 2024-11-05 schema
- Introducing separate classes for Text and Blob ResourceContents
- Custom JSON converter to allow those types to be returned, making it easier to follow the type system against the spec
- Updated tests
* Apply suggestions from code review
Co-authored-by: Stephen Toub <stoub@microsoft.com>
Co-authored-by: Peder Holdgaard Pedersen <127606677+PederHP@users.noreply.github.com>
* Putting files back where they belong
* Adding an internal constructor to prevent overloads
* Addressing feedback
* Apply suggestions from code review
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* Update src/ModelContextProtocol/Protocol/Types/ResourceContents.cs
* Addressing feedback
---------
Co-authored-by: Stephen Toub <stoub@microsoft.com>
Co-authored-by: Peder Holdgaard Pedersen <127606677+PederHP@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>
* Fix some issues with Native AOT
- An anonymous type was being used in McpClient for the initialize result message. Switched to use the type for that purpose that already existed.
- A bunch of the request params / result types were not in the source context or referenced from types that were or from custom converters. Added all the request/result types to the context.
- Improved the warning message for WithTools.
* Adding support for returning collections from tools
This will mean we can return multiple AIContent objects from a tool, such as a mixed text/image set
Contributes to #68
* Code review feedback
* Adding tests and some more cases
* More cases in switch and tests
* Add [McpServerTool] support for instance methods
By popular demand, enables [McpServerTool] on instance methods. The instance is constructed per invocation, using ActivatorUtilities.CreateInstance when possible so that constructor arguments are satisfied from DI.
* Add disposal tests
* 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 XunitLoggerProvider
* Avoid logging to stale ITestOutputHelper in fixture disposal
* Use LoggedTest base class everywhere an ILoggerFactory is used
* Fix private reflection
Two changes in this PR
- Remove private reflection from one of the tests
- Move to use `TaskCompletionSource` (feedback from previous PR)
* fix
* spelling
