* Initial plan
* Add Description property to Implementation type
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Add test to validate client Description from server perspective
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* Ignore unexpected properties when deserializing a ContentBlock
* Fix deserialization of Reference.Title and more bugs for unknown props
* Remove comments about skipping additional properties
* Initial plan
* Add SEP-1034 support for default values in all primitive schema types
Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>
* Address PR feedback: convert if-else to switch and add default value mapping tests
Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>
* Remove default value extraction code and linker annotations per feedback
Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>
* Use literal true/false values instead of GetBoolean() call
Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>
* Reinstate tests and fix CreatePrimitiveSchema to extract defaults from AttributeProvider
Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>
* Remove manual default extraction and update test to use positional record
Removed the manual default value extraction code from BuildRequestSchema
and SetDefaultValue helper as this should be handled by AIJsonUtilities.
Updated FormWithDefaults to be a positional record with optional parameters.
Test is now skipped until AIJsonUtilities supports extracting defaults from
optional parameters.
Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>
* Use 'is not null' pattern for consistency with nullable checks
Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: eiriktsarpalis <2813363+eiriktsarpalis@users.noreply.github.com>
* Initial plan
* Allow handlers for empty tool/prompt/resource collections
Changed condition from `IsEmpty: false` to `not null` check in McpServerImpl.cs for resources (line 298), prompts (line 459), and tools (line 547). This allows handlers to be synthesized even when collections are empty, enabling dynamic addition of items after initialization.
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* Decouple Handlers and Collections (e.g. ToolsHandler and ToolsCollection) from Capabilities by promoting them to the options types.
Also, group all handlers in container classes, for server, I decided to move McpServerHandlers down to Mcp.Core and move the NotificationHandlers there too.
Also, Fix ListResourceTemplatesHandler issue.
* Add remarks for empty protocol capability types
* Keep JsonIgnore properties and mark them as Obsolete
* Continue supporting Obsolete members
* Update Obsolete messages to indicate the member will be removed
* Add EditorBrowsable Never to the remaining obsolete members
* Add ElicitAsync<T> (#630)
- Refactored `ElicitResult` to a generic class `ElicitResult<T>` for typed content.
- Added `ElicitAsync<T>` method in `McpServerExtensions.cs` to request user input and construct schemas based on type `T`.
- Implemented schema building logic to handle primitive types and enums, ignoring unsupported types.
- Introduced `ElicitationTypedTests.cs` for testing the new elicitation functionality with typed forms.
- Verified naming policies in tests to ensure correct serialization casing.
- Defined `SampleForm` and `CamelForm` classes for expected input shapes, including unsupported properties for schema testing.
- Created JSON serialization contexts for both forms using source generation for improved performance.
* Fix the enum issue. for ElicitAsync<T>.
* Use AIJsonUtilities.CreateJsonSchema to create PrimitiveSchemaDefinition. #630
Renamed `BuildRequestSchemaFor<T>` to `BuildRequestSchema<T>`.
Updated the implementation to use `CreatePrimitiveSchema` and
enhanced type checks for supported primitives with
`AIJsonUtilities.CreateJsonSchema`. Streamlined handling of
unsupported types by consolidating return statements.
* Simplify ElicitAsync for schema validation. #630
Simplified the `ElicitAsync` method in `McpServerExtensions.cs` by removing unnecessary JSON object construction and directly deserializing `raw.Content`. Updated `CreatePrimitiveSchema` to use `JsonTypeInfo` for type checking and adjusted return logic for unsupported types.
In `ElicitationTypedTests.cs`, modified the `Can_Elicit_Typed_Information` test to account for the new `Created` property in `SampleForm`, increasing the expected property count from 5 to 6. Added assertions for the type and format of the `Created` property and included its deserialization in the test setup.
* Add error handling for unsupported elicitation types #630
Introduce exception handling in `McpServerExtensions.cs` for unsupported types. Add a test case in `ElicitationTypedTests.cs` to verify exception throwing for unsupported types. Define a new `UnsupportedForm` class with nested properties and include JSON serialization attributes for proper handling.
* Validate generic types in BuildRequestSchema #630
Introduce validation to ensure only object types are supported for elicitation requests in the `BuildRequestSchema` method. An exception is thrown for non-object types. Update the test suite with a new test case to verify this behavior, ensuring that an exception is raised when eliciting a non-object generic type (e.g., string) and that the elicitation handler is not invoked in this scenario.
* Move nullable types handling logic to ElicitationRequestParams.Coverter. #630
* Add schema validation for elicitation requests
Introduce `TryValidateElicitationPrimitiveSchema` method to validate JSON schemas for elicitation requests. This method checks for object type, verifies the "type" property, and ensures compliance with allowed properties based on primitive types (string, boolean, number). Integrate this validation in the `BuildRequestSchema` method to ensure generated schemas are valid before further processing.
* Refactor nullable type pattern matching. #630
* Update src/ModelContextProtocol.Core/Server/McpServerExtensions.cs
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Update src/ModelContextProtocol.Core/Server/McpServerExtensions.cs
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Update src/ModelContextProtocol.Core/Server/McpServerExtensions.cs
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Update src/ModelContextProtocol.Core/Server/McpServerExtensions.cs
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Update src/ModelContextProtocol.Core/Server/McpServerExtensions.cs
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Add ElicitResultSchemaCache. #630
* Prepopulate elicit schema validation logic. #630
- Introduced `LazyElicitAllowedProperties` to cache allowed property names for primitive types, replacing hardcoded logic.
- Streamlined `TryValidateElicitationPrimitiveSchema` method by consolidating type checks using pattern matching.
- Removed manual addition of allowed properties and now retrieve them directly from the new dictionary.
- Updated handling of "integer" type to be treated as "number" for consistency.
* Use Nullable.GetUnderlyingType to handle nullable types on elicitation. #630
- Update `ElicitRequestParams.cs` to throw a `JsonException` for non-string "type" properties, simplifying error handling.
- Modify `CreatePrimitiveSchema` in `McpServerExtensions.cs` to better handle nullable types and improve error messages.
- Revise `TryValidateElicitationPrimitiveSchema` to accept schema as the first parameter, enhancing clarity in error reporting.
- Simplify validation logic for the "type" keyword by directly retrieving string values, ensuring unsupported "type" arrays are flagged as errors.
* Rename static field.
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Fix static field renamings. #630
* Make BuildRequestSchema non-generic. #630
* Avoid closure allocation for serializerOptions on netcore #630
Updated the `GetOrAdd` method to use a generic type parameter for .NET, allowing for better handling of `JsonSerializerOptions`. Retained the original implementation for other frameworks to ensure compatibility.
* Refactor ElicitRequestParams and McpServerExtensions. #630
- Simplified "type" property handling in Converter.
- Changed s_lazyElicitAllowedProperties to nullable type.
- Updated ElicitAsync to use static lambda for clarity.
- Refactored CreatePrimitiveSchema to handle nullable types.
- Initialized allowed properties in TryValidateElicitationPrimitiveSchema.
- Updated ElicitationTypedTests for naming conventions and added tests for nullable properties.
- Enforced required properties in SampleForm and introduced NullablePropertyForm.
- Added JSON source generation context for NullablePropertyForm.
* Remove reduntant checks. #630
Refactor JSON schema type handling and add integer support
This commit simplifies the validation logic for the `type` property in the JSON schema by removing unnecessary conditional checks. It directly retrieves the string value from `typeProperty` and assigns it to `typeKeyword`. Additionally, it enhances the `s_lazyElicitAllowedProperties` dictionary to include support for the `integer` type, allowing it to be recognized as a valid type with its corresponding allowed properties.
* Add IsAccepted property and update ElicitAsync return type
- Introduced `IsAccepted` property in `ElicitResult` and `ElicitResult<T>` to indicate if the action was accepted.
- Changed `ElicitAsync<T>` to return `ValueTask<ElicitResult<T>>` instead of `ValueTask<ElicitResult<T?>>`, ensuring non-nullable results.
- Updated return statements in `ElicitAsync<T>` to reflect the new return type, treating `Content` as non-nullable.
* Rename to s_elicitAllowedProperties
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Fix renaming s_elicitAllowedProperties. #630
* Remove unnecessary json attributes. #630
* Improve xml comment
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
* Remove extra IsAccepted property. #630
* Use IsAccepted for checks.
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* Add IsAccepted to non-generic ElicitResult.
---------
Co-authored-by: Eirik Tsarpalis <eirik.tsarpalis@gmail.com>
Co-authored-by: Stephen Toub <stoub@microsoft.com>
* 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
- 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
* 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
* 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.
* 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
* 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>
