Right now by default, the client and server hardcode the initial spec version, and if there's a mismatch, the request fails.
With this change, by default both client and server are allowed to float to any supported version.
* Improve exception diagnostics for stdio client
Track the last several lines of stderr and include those in an exception created as part of CleanupAsync if the server process has already exited. This is based on an assumption that the server should never exit prior to CleanupAsync being called.
* Address feedback and fix test failure
- Add missing filling of ResourceCollection in McpServerOptionsSetup
- Remove AIFunctionMcpServerXx.ToString overrides; for resources, it was changing behavior undesirably, and for the others it was duplicate code.
- Fix notification method used for resource list changes.
- Fix type in WithResources parameter name.
- 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
* Adds test to show where trace IDs are encoded
Signed-off-by: Adrian Cole <adrian.cole@elastic.co>
* update impl to params._meta
Signed-off-by: Adrian Cole <adrian.cole@elastic.co>
---------
Signed-off-by: Adrian Cole <adrian.cole@elastic.co>
* Add SchemaCreateOptions in McpServerToolCreateOptions
* Use TransformSchemaNode for SchemaCreateOptions testing
* Add SchemaCreateOptions in McpServerPromptCreateOptions also
* Add idle session pruning tests
* Remove redundant CTS from StreamableHttpHandler
* StreamableHttpServerTransport.HandlePostRequest already creates the equivelant CTS
which DeleteRequest_CompletesSession_WhichCancelsLongRunningToolCalls verifies
* Fix accept header validation for GET
* Use InvalidOperationException for transport-not-connected errors in doc comments
* Fix flaky Cancellation_ThrowsCancellationException test
- 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
* 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>
* 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.
* 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
