Provides tools for uploading, listing, and managing files on AWS S3 buckets, including public and private file handling with temporary URLs.
Supports DigitalOcean Spaces as an S3-compatible storage provider for file management operations.
Allows integration with MinIO or other S3-compatible storage services for file upload, listing, and URL generation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@saveformedearai upload the file README.md to my documents"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for managing files on S3 storage, supporting AWS S3 and DigitalOcean Spaces.
🚀 Upload public and private files with metadata
📋 List files with descriptions and information
🔗 Immediate URL access - URLs returned directly in upload response
🌍 Global and local configuration for projects
⚡ Multi-provider support (AWS S3, DigitalOcean Spaces, S3-compatible)
🎯 Claude Code integration via MCP
Related MCP server: @zhigang1992/uploadfile-mcp
npm install -g saveformedearaigit clone https://github.com/bramato/saveForMeDearAi.git
cd saveForMeDearAi
npm install
npm run build
npm install -g .Install and configure:
npm install -g saveformedearai
saveformedearai setupAdd to Claude MCP config:
{
"mcpServers": {
"saveformedearai": {
"command": "saveformedearai"
}
}
}# Configure S3 drive (global)
saveformedearai setup
# Initialize local project
saveformedearai init
# Start MCP server (automatic when called by Claude)
saveformedearaiSaved in ~/.saveformedearai/config.json:
{
"defaultDrive": "my-aws-drive",
"drives": {
"my-aws-drive": {
"endpoint": "https://s3.amazonaws.com",
"region": "us-east-1",
"accessKeyId": "YOUR_ACCESS_KEY",
"secretAccessKey": "YOUR_SECRET_KEY",
"bucketName": "my-bucket"
}
}
}Saved in .claude/saveformedearai.json:
{
"driveName": "my-project-drive",
"projectDirectory": "my-project",
"s3Config": {
"endpoint": "https://nyc3.digitaloceanspaces.com",
"region": "nyc3",
"accessKeyId": "YOUR_DO_KEY",
"secretAccessKey": "YOUR_DO_SECRET",
"bucketName": "my-space"
}
}save_public_fileSave a file as public and return the permanent URL.
{
"filePath": "/path/to/file.jpg",
"filename": "optional-custom-name.jpg", // optional
"description": "File description" // optional
}Response:
{
"success": true,
"url": "https://bucket.endpoint.com/file.jpg",
"key": "file.jpg",
"urlType": "permanent",
"isPublic": true,
"message": "File uploaded successfully as public file. URL: https://bucket.endpoint.com/file.jpg",
"driveName": "my-drive"
}save_private_fileSave a file as private.
{
"filePath": "/path/to/private-file.pdf",
"filename": "document.pdf",
"description": "Private document"
}Response:
{
"success": true,
"key": "document.pdf",
"url": "https://presigned-url...",
"temporaryUrl": "https://presigned-url...",
"urlType": "temporary",
"expiresIn": 3600,
"expirationDate": "2024-01-15T11:30:00Z",
"message": "File uploaded successfully as private file. Temporary URL provided (expires in 1 hour).",
"driveName": "my-drive"
}list_filesList all files with metadata.
{
"prefix": "images/" // optional, filter by prefix
}Response:
{
"success": true,
"files": [
{
"filename": "image.jpg",
"description": "Sample photo",
"uploadDate": "2024-01-15T10:30:00Z",
"isPublic": true,
"size": 1024000,
"contentType": "image/jpeg",
"sizeFormatted": "1.02 MB"
}
],
"count": 1,
"driveName": "my-drive"
}get_file_urlGet URL for a file (permanent for public, temporary for private).
{
"filename": "document.pdf",
"expiresIn": 3600 // optional, seconds (max 7 days)
}Response for public file:
{
"success": true,
"url": "https://bucket.endpoint.com/document.pdf",
"urlType": "permanent",
"isPublic": true,
"filename": "document.pdf"
}Response for private file:
{
"success": true,
"url": "https://presigned-url...",
"urlType": "temporary",
"isPublic": false,
"expiresIn": 3600,
"expirationDate": "2024-01-15T11:30:00Z"
}Endpoint: https://s3.amazonaws.com
Force Path Style: falseEndpoint: https://[region].digitaloceanspaces.com
Force Path Style: falseEndpoint: https://your-endpoint.com
Force Path Style: true (typically)# Clone repository
git clone https://github.com/bramato/saveForMeDearAi.git
cd saveForMeDearAi
# Install dependencies
npm install
# Build
npm run build
# Development with watch
npm run dev
# Test locally
npm startRun saveformedearai setup to configure an S3 drive.
Verify:
Correct credentials
Correct endpoint for provider
Bucket exists and is accessible
Adequate permissions (read/write for bucket)
Use list_files to verify file names in the bucket.
MIT
Contributions are welcome! Please open an issue or pull request.
Love coding with chill vibes? Support this project by listening to my developer album:
Perfect background music for your coding sessions
Every stream helps support the development of free tools like this one! 🙏
Get a temporary or permanent URL for a file. For public files, returns permanent URL. For private files, returns temporary presigned URL.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Name/key of the file to get URL for | |
| expiresIn | No | Expiration time for presigned URLs in seconds (default: 3600 = 1 hour, max: 604800 = 7 days) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the key behavioral split (permanent URL for public files vs temporary presigned URL for private files). It omits auth/permission requirements, error behavior for a missing or inaccessible file, and whether the URL is reusable once issued.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, with the core behavior front-loaded. Every sentence carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with no annotations and no output schema, the description covers the central behavior but leaves gaps around failure modes and the scope of expiresIn. Adequate but with clear room to say more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so filename and expiresIn are already fully documented in the schema, making 3 the baseline. The description adds nothing about parameters and does not clarify that expiresIn only governs the private/presigned case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get a ... URL for a file') and cleanly separates the two output modes by file visibility. It is distinguishable from the save_*/list_files siblings, though it never names them, so it lands one step short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent can infer this is the tool for retrieving a link to an existing file, and that the result type depends on file visibility. There is no explicit when-to-use versus alternatives and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all files stored in the S3 bucket with their metadata including descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | Optional prefix to filter files (e.g., "images/" to list only files in images folder) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It mentions listing metadata but doesn't disclose key behavioral traits like whether it's read-only (implied but not stated), pagination behavior, permission requirements, or potential rate limits. For a listing tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the main action and includes relevant details about metadata. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should be more complete. It covers the basic purpose but omits behavioral details like read-only nature, return format expectations, and usage context relative to siblings. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the prefix parameter fully, including an example. The description doesn't add any parameter details beyond what's in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (files stored in S3 bucket) with additional scope (metadata including descriptions). However, it doesn't differentiate from siblings like get_file_url or save_public_file beyond the obvious 'list' vs 'save/get' distinction, leaving room for clarity but it's fairly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as get_file_url for specific file access. There's no mention of exclusions or prerequisites. Implied usage for listing, but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a file to S3 storage as private. Use get_file_url to get temporary access URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the local file to upload | |
| filename | No | Optional custom filename for the uploaded file (defaults to original filename) | |
| description | No | Optional description/metadata for the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does communicate the key trait that storage is private and that access requires a temporary URL, but says nothing about overwrite/conflict behavior, size limits, auth requirements, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the core action front-loaded before the related-tool pointer. Nothing could be cut without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description is the only source of behavioral context for this mutation. It covers what happens (private upload) and a follow-up tool, but omits return value, error behavior, and constraints, leaving it only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (including the optional filename defaulting behavior) are already documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Save') plus resource ('file to S3 storage') and a distinguishing scope ('as private'), which cleanly separates it from the sibling save_public_file without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It points to get_file_url for retrieving access URLs, which is useful follow-up routing, but gives no explicit condition for choosing this over save_public_file (the obvious alternative) and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a file to S3 storage and make it publicly accessible. Returns the public URL.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the local file to upload | |
| filename | No | Optional custom filename for the uploaded file (defaults to original filename) | |
| description | No | Optional description/metadata for the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the security-relevant behavior (file becomes publicly accessible) and that the public URL is returned, which the schema does not convey. However, it omits whether existing files are overwritten, permission/credential requirements, and size or bucket constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler; the core behavior and the return value are front-loaded. Nothing redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter upload tool with no annotations and no output schema, the description covers the essential action and the return value (public URL). Remaining gaps are minor operational details like overwrite behavior and auth, which are not fatal for a straightforward upload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description adds no additional parameter meaning (no format, path conventions, or default nuances), so the baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (save/upload) and resource (file to S3) plus the key distinguishing trait: it makes the file publicly accessible. This implicitly separates it from save_private_file, though the sibling is never named. An agent can tell it apart from list_files and get_file_url, but the public-vs-private routing is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when to use this tool versus save_private_file, nor any prerequisites or exclusions. The phrase 'publicly accessible' hints at the use case, but the agent must infer the selection rule rather than being told it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.0get_file_urllist_filessave_private_filesave_public_fileScored across 4 tools
Each tool has a distinct purpose: saving public/private files with different access semantics, listing files, and retrieving URLs. The only minor overlap is that save_public_file also returns a URL, but its primary action (saving) is clearly differentiated from get_file_url (retrieving URLs for existing files).
All tool names use snake_case and follow a verb_noun pattern (save_public_file, save_private_file, list_files, get_file_url). The convention is predictable and consistent throughout.
Four tools is a well-scoped set for a focused S3 file storage server, covering the core operations of saving, listing, and URL retrieval without unnecessary bloat.
The surface covers save (public/private), list, and URL retrieval, but lacks any delete or update/replace operation, which are important for a file storage lifecycle. There is also no way to set file descriptions or metadata despite list_files returning them.
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
MCP server for interacting with the Supabase platform
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
