🐛 Issue: GitHub extension – base64-encoded resource responses not decoded

Description

While using the GitHub extension in Goose, I encountered an issue when downloading text resources from GitHub via the MCP server.

The operation appears to succeed, but the returned content is not usable as-is:

successfully downloaded text file (SHA: a7f252576853d94f02f4c92aa42658d85268b721)

The downloaded file content is base64-encoded, and it seems that this content is not decoded before being returned to the user.

Related issue

I found that this behavior is already discussed in the GitHub MCP Server repository:

👉 github/github-mcp-server#782

In particular, this comment seems very relevant:

As a guess, this seems potentially to be an issue with the ability of the host being used here to handle resource responses.
The contents are returned as a base64 file, so I would assume this should not be serialised by the MCP host.
Does the same issue occur with resource responses in other MCP servers?

Analysis / Expected behavior

• The GitHub MCP server returns resource responses encoded in base64

• Goose (as the MCP host) appears to:

  • either serialize the response as-is
  • or not decode the base64 payload before exposing it

From a user perspective, this looks like a bug, but it is more likely a missing decoding step in the backend.

Expected behavior:

• Base64-encoded resource responses should be decoded automatically by the MCP host (Goose backend) before being exposed to the client / user.

Questions

• Is Goose expected to handle base64 decoding of MCP resource responses?

• Does Goose currently support this for other MCP servers?

• Would this decoding logic belong in:

  • the GitHub extension, or
  • the Goose MCP host layer?

Environment

• Goose version: 1.18
• GitHub extension version: streamble_http
• MCP server: github-mcp-server

Thanks for your work on Goose and the MCP ecosystem 🙏
Happy to provide more details or test a fix if needed.