get_file_contents returns [non-text content: resource] instead of file text in Claude voice mode

[15hoursweek]

Describe the bug

When using the hosted GitHub MCP connector from Claude (claude.ai), get_file_contents for a Markdown file sometimes returns no file body — the tool result only shows [non-text content: resource] instead of the file text. In my testing this happened consistently while using Claude's voice mode, while the exact same file was returned correctly in text mode within the same session.

Affected version

Hosted GitHub MCP connector (remote server via claude.ai's GitHub connector). Client: Claude (claude.ai), observed on 2026-08-31.

Steps to reproduce

1. Connect Claude (claude.ai) to the hosted GitHub MCP server.
2. In a voice-mode conversation, ask Claude to read a Markdown file via get_file_contents — e.g. README.md of this repository (github/github-mcp-server), which is where I reproduced it, so it is not specific to my own repositories.
3. The tool result contains [non-text content: resource] and no file text, so the model cannot see the file content.
4. In the same session, switching to text mode and requesting the same file returns the full content normally.

What I observed while isolating the issue

1. Mode-dependent: the failure occurred in voice mode; the same file succeeded in text mode. I confirmed both the reproduction and the recovery within a single session.
2. Workaround exists: fetching the same content via list_commits + get_commit (with detail: full_patch) returns the full file text even in voice mode.
3. Not repo-specific: reproduced with github/github-mcp-server's own README.md.
4. Not size/content-dependent: a file that failed in voice mode succeeded in text mode in the same session, so file size/content does not seem to be the deciding factor.

I searched existing issues and found #1168 (binary mimeType handling, already closed) and #1176 (resource not found error), but neither matches this symptom: here the call succeeds but the content arrives as an embedded resource the client renders as [non-text content: resource] rather than as text.

Expected behavior

get_file_contents returns the Markdown file body as text (or in a form the client can present to the model) regardless of the client conversation mode.

Additional context

My guess is that the response uses an embedded resource content type that some client surfaces (e.g. Claude's voice mode) cannot unwrap, whereas plain text content would work everywhere. If there is a way to force a plain-text response, I'm happy to test it.