[BUG] Hostinger Mail MCP server corrupts binary attachment downloads by returning them as text

[matheusroika]

Bug Description

The Hostinger Mail MCP server appears to corrupt binary attachment downloads by returning attachment bytes as text content.

The REST API endpoint works correctly when called directly with an Agentic Mail API token, but the same endpoint called through the MCP server returns binary attachment bodies inside a text response. This causes binary bytes to be decoded/serialized as text, introducing replacement characters (� / \ufffd) and making the original files impossible to reconstruct reliably.

This was reproduced with PDF, JPEG, and PNG attachments.

Affected MCP server:

https://mcp.mail.hostinger.com/mcp

MCP server info observed:

serverInfo.name = hostinger-email

Affected endpoint called through MCP:

GET /api/v1/mailboxes/{mailboxResourceId}/folders/{folder}/messages/{uid}/attachments/{attachmentId}

Steps to Reproduce

1. Connect to the Hostinger Mail MCP server at https://mcp.mail.hostinger.com/mcp.

2. Initialize the MCP session.

3. Call the MCP tool email_call_api_read.

4. Use it to call an attachment endpoint for a binary file such as PDF, JPEG, or PNG:

   GET /api/v1/mailboxes/{mailboxResourceId}/folders/{folder}/messages/{uid}/attachments/{attachmentId}

5. Inspect the MCP response.

6. Observe that the response returns result.content[0].type = "text" and includes the binary attachment body inside a text/JSON string.

Expected Behavior

The MCP server should return email attachments in a binary-safe way.

For example, the response could use one of the following:

• a file/resource artifact
• a base64-encoded payload
• a signed/download URL
• another lossless binary-safe representation

The client/agent should be able to reconstruct the exact original attachment bytes.

Actual Behavior

The MCP server returns binary attachment bodies as text.

In PDF testing, the MCP response contained:

• result.content[0].type = "text"
• internal API response status: 200
• internal Content-Type: application/octet-stream
• internal Content-Length: 641604
• body starts with %PDF
• body contains %%EOF
• body contains many replacement characters (� / \ufffd)

In one PDF test, the returned body string contained approximately 264,051 replacement characters, indicating that binary PDF bytes had already been decoded/serialized as text by the MCP layer.

The same issue was reproduced with image attachments:

• JPEG attachment returned as text, with approximately 71,753 replacement characters
• PNG attachment returned as text, with approximately 41,097 replacement characters

This indicates the problem is not PDF-specific. It affects binary attachment downloads generally.

Additional Context

Direct REST API calls to the same endpoint work correctly when using an Agentic Mail API token.

The same attachment endpoint was called directly outside the MCP server:

GET /api/v1/mailboxes/{mailboxResourceId}/folders/{folder}/messages/{uid}/attachments/{attachmentId}

Three PDF attachments were downloaded successfully through the REST API:

• PDF 1: valid PDF, 6 pages
• PDF 2: valid PDF, 5 pages
• PDF 3: valid PDF, 6 pages

All PDF files started with %PDF, had an EOF marker, and rendered correctly after being saved to disk.

A JPEG attachment was also downloaded successfully through the REST API:

• JPEG started with FF D8 FF
• JPEG ended with FF D9
• the saved image file was valid

This suggests the underlying REST API endpoint is working correctly, and the issue is in the MCP server/wrapper layer.

I could not find a public repository specifically for https://mcp.mail.hostinger.com/mcp, so I am reporting this here because it appears related to the Hostinger MCP layer. If this is not the correct repository for the Hostinger Mail MCP server, please redirect this issue to the right place.