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

Resource Mime Type is ignored #152

Open
eiseleMichael opened this issue Jan 15, 2025 · 0 comments
Open

Resource Mime Type is ignored #152

eiseleMichael opened this issue Jan 15, 2025 · 0 comments

Comments

@eiseleMichael
Copy link

Describe the bug
Setting a mime type on a Ressource using FastMCP is being ignored by the low level server as the returned type is based on the ReadResourceRequest result type.

To Reproduce
Create any resource that returns a base64 string and explicitly sets a mime type, e.g.:

@mcp.resource("hackernews://get_logo", mime_type="image/png")
def get_logo() -> str:
    """Returns the Hacker News logo."""
    with open("../data/logo.png", "rb") as image_file:
        image_bytes = image_file.read()
        base64_string = base64.b64encode(image_bytes).decode('utf-8')
        return base64_string

Invoke either directly or using the MCP inspector

{
  "method": "resources/read",
  "params": {
    "uri": "hackernews://get_logo"
  }
}

Actual behavior
It returns

{
  "contents": [
    {
      "uri": "hackernews://get_logo",
      "mimeType": "text/plain,
      "blob": "aVZCT1J3MEtHZ29B [...]
}

Note: a resource that it as bytes does not make much of a difference, it just changes the mime type to the very generic octet-stream.

{
  "contents": [
    {
      "uri": "hackernews://get_logo",
      "mimeType": "application/octet-stream",
      "blob": "aVZCT1J3MEtHZ29

Expected behavior
It should respect the mime type for both string and bytes content.

If you need a repo to reproduce it, I'm happy to help.
MCP version 1.2.0.

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

No branches or pull requests

1 participant