Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ResourceType and Resource for defining resources #72

Open
aaronpowell opened this issue Mar 23, 2025 · 6 comments
Open

Add ResourceType and Resource for defining resources #72

aaronpowell opened this issue Mar 23, 2025 · 6 comments
Labels
enhancement New feature or request

Comments

@aaronpowell
Copy link
Contributor

Is your feature request related to a problem? Please describe.
Similar to #70.

The API for McpToolType and McpTool (combined with the WithTools method) makes it really easy to define tools. It'd be great to have a comparable API for Resources.

Describe the solution you'd like
I'd like to be able to have code like this:

[ResourceType]
public static class SampleResource {
  [Resource("text/plain"), Description("This is a sample resource")]
  public static string Sample() => "test://static/resource/sample.txt";
}

// in program.cs
builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithTools()
    .WithResources();

Describe alternatives you've considered
Currently, the only solution would be to implement this via WithListResourcesHandler and WithReadResourceHandler.

@Redth
Copy link
Contributor

Redth commented Mar 23, 2025

I opened #74 to track Resource Templates separately, but I think ideally they are related to the implementation which would happen for static Resources.

@aaronpowell
Copy link
Contributor Author

Yep, looks like they are similar in theme.

@PederHP
Copy link
Collaborator

PederHP commented Apr 1, 2025

How do you provide the actual resource contents with this approach?

@aaronpowell
Copy link
Contributor Author

How do you provide the actual resource contents with this approach?

This is how I imagine it to be:

[McpServerResourceType]
public class MyResources {
    [McpServerResource("file://myresource/foo.txt"), Description("This is a foo text file")]
    public static string Foo(
        Uri uri // this would be injected by the MCP server and map to `file://myresource/foo.txt` in this case
    )
    {
        return """
        This is a foo text file.

        It could be multiple lines long.
        """;
    }

    [McpServerResource("file://myresource/bar.png", MimeType = "image/png"), Description("This is a bar image")]
    public static byte[] Bar(
        Uri uri // this would be injected by the MCP server and map to `file://myresource/bar.png` in this case
    )
    {
        return ... // PNG file content
    }

    [McpServerResource("file://myresource/baz.csv"), Description("This is a baz text file")]
    public static DataContent Baz(
        Uri uri // this would be injected by the MCP server and map to `file://myresource/baz.csv` in this case
    )
    {
        return new DataContent {
            MimeType = "text/csv",
            Blob = ... // CSV file content
        }
    }
}

These are obviously static resources routes, but the same approach could be applied to dynamic ones like file://foo/{id}, and maybe in that cause you could map a route parameter of id onto the URI segment, like in minimal API.

@Tyler-R-Kendrick
Copy link
Contributor

Tyler-R-Kendrick commented Apr 10, 2025

How would you handle providing content from something like Azure Storage as a file provider (or any other valid URIs on alternative file systems?)

Since we're already including the file provider apis in this project, why not do:

builder.WithResources([fileInfo1, fileInfo2, ...otherFileInfos]);

and just load the resources using the built-in apis for that?

@Tyler-R-Kendrick
Copy link
Contributor

Tyler-R-Kendrick commented Apr 11, 2025

I added a PR that addresses my feedback around existing packages.
I like the idea of a consistent way to provide registered types, and the addition of attributes in the design of McpServerResourceAttribute for loading types would be useful. However, I think my implementation implements the initial request at minimum and can be extended to support attribute registration.

@aaronpowell @Redth What do you all think?

For reading resources, a default or custom handler could be registered using file provider APIs that require a file provider instance to be configured in the McpServer.ServiceProvider if a custom handler isn't registered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants