Skip to main content
Glama
memoio

MEFS MCP Server

Official
by memoio
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

MEFS-MCP-SERVER

MEMO MCP Server provides a standard storage interface for AI agents, allowing AI agents to save generated content to MEFS and providing data retrieval capabilities. It provides decentralized storage for AI agents.

Use Cases

  • Encrypted data storage: Store AI-generated content to MEFS.

  • User context retrieval: Store user behavior and preference data to MEFS, and quickly retrieve relevant user data in subsequent requests to provide to AI agents.

  • Seamless data sharing: AI agents can achieve trustless data sharing through content identifiers (CID).

Related MCP server: MemoraМCP

Free Quota

Start using mefs-storage now and enjoy 10GB of free storage space.

Quick Installation Guide

You can follow the steps below to install the MCP server. Before using the MEFS MCP server, please ensure you have created an EVM private key.

Prerequisites

Before using the MEFS MCP server, please ensure you have created an EVM private key. You can use EVM wallets such as MetaMask or Okx Wallet to create a wallet and obtain your private key.

Configure MCP Server (Private Key Required)

You can start the MCP server in your client using the following configuration:

Standard Configuration - Suitable for most clients

{
  "mcpServers": {
    "mefs-storage-server": {
      "command": "npx",
      "args": ["mefs-mcp-server"],
      "env": {
        "MCP_TRANSPORT_MODE": "stdio",
        "MEFS_PRIVATE_KEY": "<YOUR-PRIVATE-KEY>",
      },
      "shell": true,
      "cwd": "./",
    },
  },
}

Replace YOUR-PRIVATE-KEY with your EVM private key obtained from the EVM wallet.

SSE Mode

The MEFS MCP Storage Server supports SSE transport mode. you can start sse mode with following step:

Clone Repository

git clone https://github.com/memoio/mefs-mcp-server.git && cd mefs-mcp-server

Install Dependencies

pnpm install

Build

pnpm run build

Start with SSE mode

pnpm run start:sse

You can configure MEFS_PRIVATE_KEY in your .env file, add MEFS_PRIVATE_KEY to your path with export command, or start the system using the following command to use your EVM private key：

MEFS_PRIVATE_KEY=<YOUR-PRIVATE-KEY> pnpm run start:sse

Configure MCP Server (SSE mode)

{
  "mcpServers": {
    "mefs-storage-server": {
      "url": "http://localhost:3001/sse",
    },
  },
}

Using MCP Tools

MEFS MCP Server provides the following tools to interact with the decentralized storage network MEFS:

Upload

Upload files to MEFS:

// Example usage in an AI application
const result = await uploadFile({  
        file: base64EncodedContent,  
        name: "document.pdf", 
    });

Parameters:

  • file: Base64-encoded file content

  • name: Filename with extension

Retrieve

Retrieve files from the MEFS network:

// Example retrieval by CID
const document = await retrieveFile({  cid: "bafybei...gq5a/document.pdf"});

Parameters:

  • cid: Unique identifier of the file

Check Remaining Space

Check remaining storage space:

const identity = await getSpace({});

Available Tools

2 tools
retrieveA

Retrieve a file from MEFS storage by its CID (Content ID). Returns the file content as a base64 encoded string.

ParametersJSON Schema
NameRequiredDescriptionDefault
cidYesThe Content ID (CID) of the file to retrieve from MEFS
keyNoDecryption key for encrypted files (optional, defaults to f1d4a0b37124c3a7 if file is not public)

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It discloses the return format but does not mention potential side effects, authorization requirements, error handling, or rate limits. The description is adequate but lacks deeper behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the purpose and return format. It is front-loaded with the verb and resource, with no extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description appropriately indicates the return type (base64 encoded string). However, it lacks details on error responses or edge cases. For a simple retrieval tool, this is nearly complete, though minor gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already provides detailed descriptions for both parameters ('cid' and 'key'). The tool description adds no new information beyond what is in the schema, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Retrieve a file'), the storage system ('MEFS storage'), and the identifier ('by its CID'). It also specifies the return format ('base64 encoded string'). This distinguishes it from the sibling tool 'upload'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool (when you have a CID to retrieve a file). However, it does not explicitly state when not to use it or mention alternatives beyond the implicit distinction from 'upload'. The guidance is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

uploadA

Upload a file to MEFS storage. The file must be provided as a base64 encoded string. Returns the CID (Mid) of the uploaded file.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesThe content of the file encoded as a base64 string
nameYesName for the uploaded file (must include file extension for MIME type detection)
keyNoEncryption key for the file (optional, defaults to f1d4a0b37124c3a7 if not public)
publicNoWhether the file should be public (default: false)

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It mentions the return value but does not disclose potential side effects, size limits, authentication needs, or whether it is destructive. The description is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each serving a distinct purpose: stating the action and adding constraints/return. No redundant or irrelevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters and no output schema, the description covers the basic action and return but misses important context like error handling, overwrite behavior, or prerequisites. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes each parameter. The description adds the base64 encoding requirement, which is also in the schema, providing little extra value beyond what is already structured.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Upload a file to MEFS storage) and the resource (file to MEFS storage), and the sibling tool 'retrieve' indicates a distinct purpose. The return of CID is also specified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when uploading a file, but lacks explicit when-to-use or when-not-to-use guidance, and does not mention alternatives or prerequisites beyond base64 encoding.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv1.0.0
    • First observedretrieve
    • First observedupload
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves a file by CID, the other uploads a file. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names are single lowercase verbs ('retrieve', 'upload') following a consistent pattern.

Tool Count3/5

With only two tools, the server feels thin for a storage system, but it covers the core upload and retrieve operations. It is borderline but reasonable for a very focused use case.

Completeness2/5

Obvious gaps exist: there is no tool for listing stored files, deleting files, or updating existing content. These missing operations will cause agent failures if management beyond upload/retrieve is needed.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/memoio/mefs-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server