Report on MCP Storage Server Issues by Devs trying integration with Storacha

[seetadev]

⚠️ MCP Storage Server Issues

We wish to share that a user integrating Eth Elder Ease modules with the MCP storage server is encountering the following issues. The user is operating on a Linux machine. Our Storacha modules are working as expected.

1. File Retrieval Content Mismatch

• Symptom:
  Upload, retrieve, and identity commands are functioning as expected from the CLI interface. Please visit https://drive.google.com/drive/folders/1FRh7noBdOc_t32dEndWdLz8zd7gWbo2Z?usp=sharing .

  However, when a file is uploaded and then retrieved, the returned content does not match the original file.

• Observation:

  • The retrieved content is consistently different, and appears partially malformed (e.g., starts with **e), across multiple retrieval attempts.
  • The same incorrect content appears in multiple retrieved files, indicating a systemic issue rather than randomness.
  • File IDs, CIDs, uploaded bytes, and metadata were all verified to match the originals during upload.

• Hypothesis:
  There may be an issue in base64 decoding or content serialization on the retrieval path. Suspected causes:

  • Corrupted encoding during upload.
  • Improper decoding from base64 or character encoding mismatch on retrieval.
  • Incomplete or misaligned chunk reconstruction if using multipart storage.

• Action Suggested:

  • Isolate encoding/decoding step from CLI storage to file system.
  • Compare raw retrieved byte stream vs original uploaded stream.
  • Validate encoding consistency across CLI and programmatic APIs (especially in text vs binary modes).

2. mcp CLI Shell Issues (Installation & Functionality)

• Symptom:
  The mcp CLI installed via Homebrew (brew install mcp) yields version 0.7.x, which is outdated and incompatible with current Storacha protocol endpoints.

• Problems Observed:

  • Basic commands like upload, retrieve, and identity fail or return malformed output.
  • Shell lacks support for new identity schema or access token-based workflows.
  • No clear upgrade path via Homebrew for newer versions (0.10.x+).

• Attempted Solutions:

  • Tried alternate installation methods but none provided up-to-date or properly configured binaries.
  • Documentation appears mismatched or outdated for CLI users installing from standard OS package managers.

• Action Suggested:

  • Provide a verified installation path (e.g., direct download from GitHub releases or a custom install script).
  • Update or replace the Homebrew formula to point to latest stable release.
  • Add version guard in CLI to warn users if using unsupported versions (e.g., <0.9.0).

[jamiechicago312]

Pulling in @fforbeck for assistance and review

[fforbeck]

@seetadev / @jamiechicago312 Could you pls provide, in text, the exact step you followed to find this issue? Sounds like we have a mismatch between the encoding (standard vs multiformats) and decoding logic (especially with prefix handling) that is potentially causing the issue reported. I think we need to tighten the symmetry between the encode and decode steps, and ensure prefix handling is identical on both ends. Do you guys want to propose a PR on that?
Relevant methods:

• https://github.com/storacha/mcp-storage-server/blob/0a339824568e3809b006dc039e2fd0f6b133e3c8/src/core/storage/utils.ts#L99C17-L99C30
• https://github.com/storacha/mcp-storage-server/blob/0a339824568e3809b006dc039e2fd0f6b133e3c8/src/core/storage/utils.ts#L125

[seetadev]

@fforbeck : Hi Felipe. Thank you so much for the quick response and for pointing us to the relevant parts of the codebase.

Following our in-depth discussion yesterday, Kartik opened two issues — each well-documented with exact steps, screenshots, and screencasts to illustrate the behavior. You can find them here:

storacha/mcp-storage-server#27

storacha/mcp-storage-server#28

Indeed, it does appear that the issue arises due to a mismatch in the encoding and decoding logic, specifically around how prefixes are being handled between standard Base58 strings and multiformats.

Completely agree with the feedback that tightening the symmetry between the encode/decode layers and aligning prefix expectations on both ends should solve this issue. We'd be happy to help move this forward and will spend quality time studying the code references shared. Appreciate your support.