The MinIO PUT MCP Server is a write‑only archiving tool that supports:
Single file upload (put_file): Upload a local file to a MinIO bucket with automatic path organization and companion metadata generation.
Batch upload (put_files): Upload multiple local files in one call, sharing date and source identifiers while assigning unique file IDs and isolating individual failures.
URL streaming (put_stream): Fetch data from a remote URL and stream it directly into MinIO without local storage, suitable for large files; content type can be inferred or manually set.
Automatic structured paths: Objects are stored under bucket/did/sid/fid, where did is the date (yyyy-mm-dd), sid is a source fingerprint (auto‑generated from hostname/MAC or user‑provided), and fid is a unique UUID.
Automatic metadata: Every upload creates a sidecar JSON file recording the original input, upload result (etag, versionId), timestamp, and any errors for full auditability.
Strict PUT‑only design: No read or delete operations are permitted, ensuring data integrity and compliance with archival requirements.
CLI configuration: Endpoint, port, access keys, region, and default path components can be set via command‑line arguments.
AI agent integration: Supports npx and node.exe driving methods for seamless embedding into automated workflows.
Overall, the server provides a minimal, secure, and auditable ingestion pipeline into MinIO object storage.
Allows uploading files and data streams to MinIO storage with automatic path organization (date/source/file), metadata generation, and audit trails. Provides tools for single file upload, batch upload, and streaming upload from URLs.
Click on "Install 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., "@MinIO PUT MCP Server Upload report.pdf to archive bucket"
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.
PUT-only 的 MinIO MCP 服务器 — 只上传、不查询、不删除，专为数据归档与写入场景设计。
https://github.com/zymeli/minio-put-mcp.git
Related MCP server: @zhigang1992/uploadfile-mcp
需要将文件、数据流归档到 MinIO 存储
审计合规要求：按 日期/机器/文件 三级路径自动组织存储结构
杜绝误删、误读操作，服务器只开放上传权限
每次上传的 目标路径 由三个标识串联而成：
存储桶 / <did> / <sid> / <fid>标识 | 全称 | 说明 |
| Date ID | 日期， |
| Source ID | 来源机器标识，32 位 MD5 hex |
| File ID | 文件标识，UUID v4 格式 |
my-bucket/2026-07-29/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6/550e8400-e29b-41d4-a716-446655440000每个文件上传后，还会自动生成一个 元数据 JSON 文件，存储在相同路径但附加 .json 后缀：
my-bucket/2026-07-29/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6/550e8400-e29b-41d4-a716-446655440000.json元数据文件记录了原始输入信息、上传结果和精确时间戳，便于后续审计与追踪。
服务启动时可通过 --help 或 -h 参数查看完整的帮助说明：
node build/index.js --help帮助信息包含所有启动参数说明、工具列表、返回值格式和示例，输出到 stderr。
包已发布到 npm，可直接全局安装，无需克隆仓库：
npm install -g minio-put-mcp安装后可直接用 minio-put-mcp 命令启动：
minio-put-mcp --endpoint=192.168.1.100 --port=9000 --access-key=YOUR_ACCESS_KEY --secret-key=YOUR_SECRET_KEY无需安装，npx 会自动从 npm 拉取并运行（-y 跳过确认）：
npx -y minio-put-mcp --endpoint=192.168.1.100 --port=9000 --access-key=YOUR_ACCESS_KEY --secret-key=YOUR_SECRET_KEYgit clone https://github.com/zymeli/minio-put-mcp.git
cd minio-put-mcp
npm install
# 编译
npm run build支持 node.exe 与 npx 两种驱动方式，任选其一即可。
npx 会自动从 npm 拉取最新版本包，无需手动安装：
{
"mcpServers": {
"minio-put-mcp": {
"command": "npx",
"args": [
"-y",
"minio-put-mcp",
"--endpoint=192.168.1.100",
"--port=9000",
"--access-key=YOUR_ACCESS_KEY",
"--secret-key=YOUR_SECRET_KEY"
]
}
}
}Windows 提示：部分 AI Agent（如 Claude Desktop）需要将
command写为npx.cmd才能正确识别。
需先在本地安装包或克隆源码编译，再指向 build/index.js：
{
"mcpServers": {
"minio-put-mcp": {
"command": "node",
"args": [
"D:/path/to/minio-put-mcp/build/index.js",
"--endpoint=192.168.1.100",
"--port=9000",
"--access-key=YOUR_ACCESS_KEY",
"--secret-key=YOUR_SECRET_KEY"
]
}
}
}安全提示：密钥会明文出现在 mcp.json 中，请确保该文件仅本人可读写，或改用环境变量传递。
node build/index.js \
--endpoint=192.168.1.100 \
--port=9000 \
--access-key=YOUR_ACCESS_KEY \
--secret-key=YOUR_SECRET_KEY \
[--use-ssl=false] \
[--region=us-east-1] \
[--did=2026-07-29] \
[--sid=abc123...] \
[--fid=550e8400-...]参数 | 必需 | 说明 |
| 是 | MinIO 服务器地址 |
| 否 | 端口，默认 |
| 是 | 访问密钥 |
| 是 | 秘密密钥 |
| 否 | 是否使用 SSL，默认 |
| 否 | 区域设置 |
| 否 | 日期 |
| 否 | 32 位 MD5 hex，未指定时根据本机硬件指纹自动生成 |
| 否 | UUID 格式，未指定时随机生成（单文件模式优先使用） |
当不指定 --sid 时，服务器启动时自动收集本机以下信息：
主机名（os.hostname()）
所有非零网络接口 MAC 地址
将以上信息拼接后取 MD5，生成 32 位 hex 作为默认识别 ID。同一台机器多次启动结果一致。
put_file — 上传单个文件输入参数：
{
"bucketName": "my-bucket",
"filePath": "D:\\report.pdf",
"metadata": { "department": "finance" }
}执行效果：
自动生成目标路径 did/sid/fid
上传文件本体
上传元数据 JSON（含 etag、时间戳等）
put_files — 批量上传文件输入参数：
{
"bucketName": "my-bucket",
"files": [
{ "filePath": "D:\\photo1.jpg", "metadata": { "tag": "travel" } },
{ "filePath": "D:\\photo2.jpg" }
]
}执行效果：
共享同一 did 和 sid
每个文件独立生成 fid
逐个上传，失败不影响后续文件
put_stream — 流式上传（从 URL 源）输入参数：
{
"bucketName": "my-bucket",
"sourceUrl": "https://example.com/large-audio.mp3",
"contentType": "audio/mpeg",
"metadata": { "description": "会议录音" }
}执行效果：
从 sourceUrl 获取数据，流式直传 MinIO
数据不落盘、不占用内存，适合音视频等大文件
自动从 HTTP 响应头推导 content-type
所有 MCP 工具执行完成后，返回值即是上传到 MinIO 的元数据 JSON 文件内容，
与服务器上 <did>/<sid>/<fid>.json 中存储的数据完全一致。
工具 | 返回格式 |
| 单个元数据 JSON 对象 |
| 单个元数据 JSON 对象 |
| 元数据 JSON 对象数组 |
put_file / put_stream){
"schema": "https://github.com/zymeli/minio-put-mcp",
"objectName": "2026-07-29/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6/550e8400-e29b-41d4-a716-446655440000",
"did": "2026-07-29",
"sid": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"fid": "550e8400-e29b-41d4-a716-446655440000",
"originalInput": {
"bucketName": "my-bucket",
"filePath": "D:\\report.pdf",
"metadata": { "department": "finance" }
},
"putResult": {
"etag": "\"5d41402abc4b2a76b9719d911017c592\"",
"versionId": null
},
"timestamp": "2026-07-29T10:30:00.000Z"
}put_files 批量)[
{
"schema": "https://github.com/zymeli/minio-put-mcp",
"objectName": "2026-07-29/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6/550e8400-e29b-41d4-a716-446655440000",
"did": "2026-07-29",
"sid": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"fid": "550e8400-e29b-41d4-a716-446655440000",
"originalInput": { ... },
"putResult": { "etag": "...", "versionId": null },
"timestamp": "2026-07-29T10:30:00.000Z"
},
{
"schema": "https://github.com/zymeli/minio-put-mcp",
"objectName": "2026-07-29/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6/660e8400-e29b-41d4-a716-446655440001",
"did": "2026-07-29",
"sid": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"fid": "660e8400-e29b-41d4-a716-446655440001",
"originalInput": { ... },
"putResult": { "etag": "", "versionId": null },
"timestamp": "2026-07-29T10:30:01.000Z",
"error": "文件不存在: D:\\missing.jpg"
}
]上传完成后，每个文件对应一个 .json 元数据文件，内容示例如下：
{
"schema": "https://github.com/zymeli/minio-put-mcp",
"objectName": "2026-07-29/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6/550e8400-e29b-41d4-a716-446655440000",
"did": "2026-07-29",
"sid": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"fid": "550e8400-e29b-41d4-a716-446655440000",
"originalInput": {
"bucketName": "my-bucket",
"filePath": "D:\\report.pdf",
"metadata": { "department": "finance" }
},
"putResult": {
"etag": "\"5d41402abc4b2a76b9719d911017c592\"",
"versionId": null
},
"timestamp": "2026-07-29T10:30:00.000Z"
}字段 | 说明 |
| JSON schema 来源，指向项目仓库，AI Agent 可借此理解各字段含义 |
| 文件在存储桶内的落盘路径，格式 |
| 本次会话的日期标识 |
| 本次会话的来源机器标识 |
| 本次上传文件的唯一标识 |
| 用户上传时传入的原始参数 |
| MinIO 返回的上传结果（etag、versionId），失败时 etag 为空 |
| 上传完成的精确时间（ISO 8601） |
| （仅失败时存在）错误描述信息 |
# 启动监听编译
npm run dev
# 编译
npm run build
# 启动服务（需先连接 MinIO）
npm run start -- --endpoint=... --access-key=... --secret-key=...运行时: Node.js >= 18.0
语言: TypeScript 5.x
MCP 协议: @modelcontextprotocol/sdk ^1.0.0
MinIO 客户端: minio ^8.0.1
数据校验: zod ^3.22.4
上传单个本地文件到 MinIO。自动构建目标路径为 did/sid/fid，并上传元数据 JSON。返回元数据 JSON 对象 (含 did/sid/fid/originalInput/putResult/timestamp)。
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | 本地文件路径 | |
| metadata | No | 文件元数据（可选） | |
| bucketName | Yes | 目标存储桶名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the automatic path construction and metadata upload, and specifies the return value. However, it does not disclose error handling, overwrite behavior, or permission requirements, leaving some gaps for a mutating operation.
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?
The description is concise, consisting of two sentences that front-load the main action and efficiently cover the purpose, behavior, and return value. No unnecessary information is present.
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 the moderate complexity (3 parameters, nested object, no output schema), the description adequately covers the tool's action, return format, and key behavioral detail (path construction). It is missing some context about siblings and error scenarios, but overall is fairly complete.
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?
The schema already covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds value by explaining the automatic path construction (did/sid/fid), which is not in the schema, thereby enhancing understanding of the filePath and metadata parameters.
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?
The description clearly states the tool uploads a single local file to MinIO, automatically builds a path structure, and uploads metadata JSON. The word '单个' (single) distinguishes it from the sibling tool 'put_files', which implies multiple files.
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 explicit guidance on when to use this tool versus alternatives like put_files or put_stream is provided. The description only implies it is for single local files, but does not mention exclusions or context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
批量上传多个本地文件。共享同一 did/sid，每个文件独立生成 fid。返回元数据 JSON 对象数组。
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | 文件列表 | |
| bucketName | Yes | 目标存储桶名称 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a metadata array and that files share did/sid but have independent fids. However, it does not mention potential errors, size limits, permissions, or idempotency, which are important for a batch upload tool.
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?
The description is a single dense sentence that conveys key information efficiently. It is front-loaded with the primary action ('batch upload multiple local files'). However, it could be slightly restructured for better readability.
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 the lack of an output schema, the description adequately explains the return type (array of metadata JSON objects). However, it omits important context like error handling, file size limits, or prerequisites, which are needed for a complete understanding of the tool's behavior.
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% (both 'files' and 'bucketName' have descriptions). The description adds value by explaining batch behavior and the output format, which is not in the schema. This elevates understanding beyond the schema alone.
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?
The description clearly states the tool uploads multiple local files in batch, sharing the same did/sid, with each file generating its own fid, and returning an array of metadata JSON objects. This distinguishes it from sibling tools put_file and put_stream. However, the terms 'did/sid' are not explained, slightly reducing clarity.
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?
The description implies usage for batch uploads via the word '批量' (batch), but provides no explicit when-to-use or when-not-to-use guidance compared to the sibling tools put_file (single file) and put_stream (streaming). The context is clear but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从 URL 源流式上传数据到 MinIO。数据不落盘，适合大文件。返回元数据 JSON 对象。
| Name | Required | Description | Default |
|---|---|---|---|
| metadata | No | 文件元数据（可选） | |
| sourceUrl | Yes | 数据源 URL（如音频/视频文件地址） | |
| bucketName | Yes | 目标存储桶名称 | |
| contentType | No | 内容类型（如 audio/mpeg） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behaviors: streaming (no disk), returns metadata JSON. Lacks details on error handling or auth, but sufficient for a simple upload tool.
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 sentences, no waste, front-loaded with core purpose. Efficient and clear.
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 4 parameters (2 required), no output schema, but mentions return type (metadata JSON). Context from sibling tools (put_file, put_files) helps differentiate. Adequately complete for this complexity.
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 coverage is 100%, so description adds no extra parameter meaning beyond schema. 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?
Description clearly states streaming upload from URL to MinIO, no disk landing, suitable for large files. Distinguishes from siblings like put_file and put_files by specifying stream and URL source.
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?
Explicitly states suitability for large files ('适合大文件') and data not landing on disk ('数据不落盘'), giving context for when to use. No explicit when-not or alternatives, but clear enough.
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. Dates show when Glama detected each change.
v1.0.1put_fileput_filesput_stream三个工具分别针对单文件上传、批量上传和流式上传，目的清晰不重叠。
所有工具使用一致的 put_ 前缀加具体对象（file, files, stream），命名模式统一。
3个工具完美覆盖服务器主题（上传到MinIO），数量适中，无冗余。
覆盖了单文件、批量、流式三种上传场景，但缺少列出或删除等管理操作，不过服务器名称限定了PUT操作。
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
MCP server for detecting and redacting PII (Personally Identifiable Information) in PDF documents.
MCP server for Riveter's enrichment, scraping, and monitoring API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zymeli/minio-put-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
