Skip to main content
Glama
chrishayuk

chuk-mcp-s3-bucket-manager

by chrishayuk
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

CHUK MCP S3 Bucket Manager

Overview

The CHUK MCP S3 Bucket Manager is a Python-based tool for managing Amazon S3 buckets using the MCP (Model Context Protocol) runtime. This utility provides a simple interface for listing, creating, and deleting S3 buckets.

Related MCP server: MinIO MCP Server

Features

  • List all S3 buckets

  • Create new S3 buckets

  • Delete existing S3 buckets

  • Optional force deletion of buckets (clearing all objects)

  • Supports custom AWS endpoint and region configuration

Prerequisites

  • Python 3.11+

  • AWS credentials configured

  • Required dependencies (installed automatically via pip)

Installation

You can install the package directly from the repository:

pip install git+https://github.com/chrishayuk/chuk-mcp-s3-bucket-manager.git

Configuration

Environment Variables

  • AWS_ENDPOINT_URL_S3: Optional custom S3 endpoint URL

  • AWS_REGION: AWS region (defaults to us-east-1)

Configuration File

The project uses a config.yaml file to configure the MCP server settings:

host:
  name: "chuk-mcp-s3-bucket-manager"
  log_level: "INFO"

server:
  type: "stdio"

mcp_servers:
  s3_bucket_manager:
    enabled: true
    location: "."
    tools:
      enabled: true
      module: "chuk_mcp_s3_bucket_manager.tools"

Usage

Command-Line Interface

# List buckets
chuk-mcp-s3-bucket-manager list_buckets

# Create a new bucket
chuk-mcp-s3-bucket-manager create_bucket --bucket_name my-new-bucket

# Delete a bucket
chuk-mcp-s3-bucket-manager delete_bucket --bucket_name my-bucket

# Force delete a bucket (remove all objects first)
chuk-mcp-s3-bucket-manager delete_bucket --bucket_name my-bucket --force

Programmatic Usage

from chuk_mcp_s3_bucket_manager import tools

# List buckets
buckets = tools.list_buckets()

# Create a bucket
result = tools.create_bucket("my-new-bucket")

# Delete a bucket
result = tools.delete_bucket("my-bucket", force=False)

Development

Setup

  1. Clone the repository

  2. Create a virtual environment

  3. Install development dependencies:

pip install -e .[dev]

Running Tests

pytest tests/

Dependencies

  • boto3

  • chuk-mcp-runtime

  • pydantic

  • PyYAML

License

[Specify your license here]

Contributing

Contributions are welcome! Please submit pull requests or open issues on the GitHub repository.

Support

For issues or questions, please file an issue on the GitHub issue tracker.

Available Tools

3 tools
create_bucketC

Create a new S3 bucket

ParametersJSON Schema
NameRequiredDescriptionDefault
bucket_nameYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist to declare safety or mutation, and the description adds no behavioral context such as idempotency, permission needs, failure modes, or side effects. 'Create' implies mutation but nothing more.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no waste. It is concise, though it could have used the space to add useful detail without becoming verbose.

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

Completeness2/5

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

With no output schema or annotations, the description should at least mention what happens on success or important constraints. It provides none, making it insufficient for an agent to fully understand invocation outcomes.

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

Parameters2/5

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

The schema has 0% description coverage, and the description does not explain bucket_name semantics (e.g., naming rules, uniqueness, format). It merely repeats the action without adding value beyond the raw parameter name.

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 uses the specific verb 'Create' with the resource 'S3 bucket', clearly identifying the tool's action. It distinguishes from siblings list_buckets and delete_bucket by the action verb.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. No prerequisites, context, or exclusions are provided; the description only states the basic action.

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

delete_bucketC

Delete an S3 bucket

ParametersJSON Schema
NameRequiredDescriptionDefault
forceYes
bucket_nameYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action ('delete'), making the destructive nature implicit but failing to disclose the 'force' parameter's effect (e.g., deleting non-empty buckets) or irreversibility.

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

Conciseness3/5

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

The description is a single concise sentence, but it under-specifies an operation that has a nontrivial parameter ('force'). It is not verbose, but the extreme brevity limits its usefulness.

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

Completeness2/5

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

Given the lack of annotations, output schema, and schema descriptions, the tool description is insufficient. It doesn't mention error conditions, whether force is required for non-empty buckets, or any safety implications, making it incomplete for a destructive operation.

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

Parameters1/5

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

Schema coverage is 0%, and the description does not explain any parameters. 'bucket_name' is self-evident from its name, but 'force' is a boolean with no explanation of its meaning or when to set it, leaving the agent without critical parameter understanding.

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 tool's purpose with a specific verb ('Delete') and resource ('an S3 bucket'), distinguishing it from sibling tools list_buckets and create_bucket.

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?

Usage is implied (use when you want to remove an S3 bucket) but no explicit context or alternatives are provided. It doesn't mention prerequisites like the bucket existing or being empty.

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

list_bucketsA

List all S3 buckets

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. The verb 'list' implies a read-only operation, but the description does not explicitly state that it has no side effects or mention any permissions or rate limits. For a simple list operation, this is acceptable but could be more explicit.

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, brief sentence that fully conveys the tool's purpose. Every word earns its place with no redundancy or unnecessary detail.

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

Completeness5/5

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

The tool is extremely simple with no parameters and no output schema. The description fully covers the tool's behavior and scope. There is no missing information that would hinder an agent from using it correctly.

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

Parameters4/5

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

The tool has zero parameters, so the schema is empty and this dimension is not applicable. Per the rubric, a baseline of 4 is appropriate when there are no parameters to describe.

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 'List all S3 buckets' uses a specific verb ('list') and clearly identifies the resource ('S3 buckets') and scope ('all'). This clearly differentiates it from the sibling tools create_bucket and delete_bucket.

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 context is clear: the tool lists buckets, which is distinct from creating or deleting. There are no exclusions or alternative tools mentioned, but the name and description make the usage obvious given the sibling tool names.

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.

  1. 3 tool updatesv0.1.1
    • First observedcreate_bucket
    • First observeddelete_bucket
    • First observedlist_buckets
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation5/5

The three tools—list, create, delete—are clearly distinct actions on S3 buckets with no overlap. An agent can easily select the right tool based on the desired operation.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (list_buckets, create_bucket, delete_bucket), making the set predictable and easy to navigate.

Tool Count5/5

With only three tools, the set is minimal but perfectly scoped for a basic S3 bucket manager. Each tool covers an essential operation without redundancy.

Completeness3/5

The set covers list, create, and delete, but lacks an update operation and a way to fetch details of a specific bucket. While list_buckets can serve as a read, the absence of update leaves a notable gap for a 'manager'.

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

  • S3 MCP Server

    rccyx
    A
    license
    Not graded
    quality
    F
    maintenance
    Enables interaction with AWS S3 through MCP, supporting bucket and object management, lifecycle configurations, tagging, policies, CORS settings, presigned URLs, and file uploads/downloads.
    3
    MIT

  • MinIO MCP Server

    Raphaelren
    F
    license
    A
    quality
    D
    maintenance
    Provides tools for interacting with MinIO and S3-compatible object storage through MCP clients like Claude. It enables comprehensive bucket and object management, including listing, creating, uploading, and generating presigned URLs.
    13
    2
    -

  • bucket-helper-mcp

    warith-harchaoui
    A
    license
    Not graded
    quality
    A
    maintenance
    Provides MCP tools for AWS S3 and S3-compatible storage, enabling file upload, download, listing, deletion, and temporary remote file staging via natural language.
    BSD 3-Clause