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.
* 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
* Add SchemaCreateOptions in McpServerToolCreateOptions
* Use TransformSchemaNode for SchemaCreateOptions testing
* Add SchemaCreateOptions in McpServerPromptCreateOptions also
* 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
