MCP Resources without parameters don't work without mime-type specified

[jamesmontemagno]

Describe the bug
Create a new MCP Server with the sample code:

 [McpServerResourceType]
    public sealed class SimpleResources
    {
        [McpServerResource, Description("Some neat direct resource")]
        public static string SomeNeatDirectResource() => "This is a neat resource";

        [McpServerResource, Description("Some neat resource with parameters")]
        public static string SomeNeatTemplatedResource(string name) => $"This is a neat resource with parameters: {name}";
    }

If you call SomeNeatTemplatedResource it will work and ask you for the name, but if you call SomeNeatDirectResource it fails

To Reproduce
Steps to reproduce the behavior:
1.

Expected behavior
A clear and concise description of what you expected to happen.

Logs
If applicable, add logs to help explain your problem.

Additional context
Add any other context about the problem here.

[jamesmontemagno]

@eiriktsarpalis I will test out this as well, i didn't see it, https://github.com/modelcontextprotocol/csharp-sdk/blob/main/samples/EverythingServer/Resources/SimpleResourceType.cs

[eiriktsarpalis]

I will test out this as well, i didn't see it

Seems to be working as expected when run against the MCP inspector

[jamesmontemagno]

So it looks like the everythign work because it has the mimetype...

    [McpServerResource, Description("Get details of a baboon monkey")]
    public async Task<string> Baboon()
    {
        var baboon = await monkeyService.GetMonkey("Baboon") ?? throw new Exception($"Baboon not found");
        return JsonSerializer.Serialize(baboon, MonkeyContext.Default.Monkey);
    }

this fails...

But this will work:

    [McpServerResource(UriTemplate = "monkeymcp://monkeys/baboon", Name = "Baboon", MimeType = "application/json")]
    [Description("Get details of a baboon monkey")]
    public async Task<string> Baboon()
    {
        var baboon = await monkeyService.GetMonkey("Baboon") ?? throw new Exception($"Baboon not found");
        return JsonSerializer.Serialize(baboon, MonkeyContext.Default.Monkey);
    }

maybe we need to apply a default mimetype?

[stephentoub]

We could default to application/octet-stream if doing so helps unblock consumption. That's basically "here are some bytes, I hope you know what to do with them". Of course a client might still fail because it doesn't know what to do with them.

[eiriktsarpalis]

So, I found two separate issues while looking into this:

• Resources that do not specify a mimetype fail in the MCP inspector when validating the response:

  [ { "code": "invalid_union", "unionErrors": [ { "issues": [ { "code": "invalid_type", "expected": "string", "received": "null", "path": [ "contents", 0, "mimeType" ], "message": "Expected string, received null" } ], "name": "ZodError" }, { "issues": [ { "code": "invalid_type", "expected": "string", "received": "null", "path": [ "contents", 0, "mimeType" ], "message": "Expected string, received null" }, { "code": "invalid_type", "expected": "string", "received": "undefined", "path": [ "contents", 0, "blob" ], "message": "Required" } ], "name": "ZodError" } ], "path": [ "contents", 0 ], "message": "Invalid input" } ]

• Resources specifying a URI template with cased letters are failing because VS Code is converting them to lowercase and our servers perform case sensitive lookups.

  Server (AspNetCoreSseServer 1.0.0.0), Client (Visual Studio Code 1.101.0) method 'resources/read' request handler failed.
  ModelContextProtocol.McpException: Unknown resource URI: 'resource://nouritemplateresource'
  

[mikekistler]

We could default to application/octet-stream if doing so helps unblock consumption.

That's on the server-side, right? On the client-side we should make sure there is no requirement for a mime-type since it is not required by the spec (if I understand correctly).

[stephentoub]

Resources that do not specify a mimetype fail in the MCP inspector when validating the response

That's a bug in the inspector, right? According to the spec, MIME type is not required.

Resources specifying a URI template with cased letters are failing because VS Code is converting them to lowercase and our servers perform case sensitive lookups

URIs are case-sensitive, other than the scheme/host. This would be a bug in VS Code then, right?

[eiriktsarpalis]

This would be a bug in VS Code then, right?

It's a bug on our side, we index resources by string so we're not responding correctly if the client changes the casing of the host.

[stephentoub]

we index resources by string so we're not responding correctly if the client changes the casing of the host.

But even if we fix the host casing, it would still be an VS Code bug for casing changes in the rest of the URI, no? Or it's only changing casing in the scheme/host and not in the rest of the URI?

[eiriktsarpalis]

In the impacted use case it's only lowercasing the host.