Commit graph csharp-sdk/src/ModelContextProtocol/Protocol/Types/ReadResourceRequestParams.cs
Author SHA1 Message Date
Stephen Toub
106ab8064f
Clean up namespaces (#410)
No meaningful code changes, just lots of namespace shuffling to have fewer namespaces and to put things in better namespaces.
2025-05-14 14:50:26 -04:00
Stephen Toub
d86b3277d4
Add McpServer/ClientResource{Template} and friends (#391)
* 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
2025-05-09 18:21:11 -04:00
Rob Chambers
77871c5aac
AI seeded comments from robch and then edited by stephentoub (#238)
* AI generated `///` comment updates

* Fix compilation issues

* Fix incorrect XML comment structure

* Update all Client comments

* Update all Configuration comments

* Update all Messages comments

* Update all Transport comments

* Update all Types comments

* Update all Server comments

* Undo some commenting

---------

Co-authored-by: Stephen Toub <stoub@microsoft.com>
2025-04-10 01:30:44 -04:00
Stephen Toub
62e92fa154
Add ToolAnnotations support (#124)
* Add ToolAnnotations support

* Address feedback
2025-03-28 11:08:29 -04:00
Aaron Powell
6fa1443a6c
Adding a base class for request params that exposes the progressToken (#99)
* Adding a base class for request params that exposes the progressToken

This aligns more with the type structure see in the other SDK's (eg: https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/types.py#L41) while also ensuring they are exposing the JSONRPCRequest (https://github.com/modelcontextprotocol/specification/blob/main/schema/2024-11-05/schema.json#L771-L806) data.

Storing progressToken as an object as it could be an int or string (per https://github.com/modelcontextprotocol/specification/blob/main/schema/2024-11-05/schema.json#L1268-L1274).

Fixes #67

* Using usings

* Apply suggestions from code review

---------

Co-authored-by: Stephen Toub <stoub@microsoft.com>
2025-03-25 23:40:48 -04:00
Eirik Tsarpalis
c9ed453745 Rename project and namespaces 2025-03-19 15:02:38 +02:00
Renamed from src/mcpdotnet/Protocol/Types/ReadResourceRequestParams.cs (Previous history)