* Initial plan
* Add McpMetaAttribute and integrate with tools, prompts, and resources
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Add tests and sample usage for McpMetaAttribute
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Add Meta property to options classes and update logic to merge with attributes
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Fix missing using directives and clarify McpMetaAttribute documentation
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Make Name and Value constructor parameters in McpMetaAttribute and check AIFunction.Metadata.UnderlyingMethod
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Change Value type to object and use JsonSerializer.SerializeToNode, fix nullable warnings
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Fix UnderlyingMethod property path, use SerializerOptions, and fix JsonObject cref
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Simplify MethodInfo resolution to use function.UnderlyingMethod directly
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Fix IL2026 trimming warning by providing type info to JsonSerializer.SerializeToNode
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Fix remaining issues
* Revert to string-based JSON values for McpMetaAttribute with StringSyntax annotation
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Add StringSyntax attribute to Value property and fix sample code to use escaped quotes
Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>
* Fix tests and a bit of cleanup
* Change approach and add lots of tests
* Use JsonContext for serialization and fix floating point test comparison
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>
* 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
We special-case string enumerables, translating them to an array of text content blocks, but other enumerables just get serialized, and there's a reasonable expectation that returning a string[] would produce a JSON array of strings. Just delete the special-casing.
* 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>
