Which integrations are available for this server?

Provides tools for comprehensive AWS S3 Tables management, including table bucket and namespace operations, table CRUD and query operations, metadata and maintenance management, and data import (CSV, Parquet, row append).

How do I use AWS S3 Connector MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AWS S3 Connector MCP Server list my S3 table buckets" 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.

AWS S3 Connector MCP Server

by sourav-spd

Overview Schema Source Related Servers Discussions Admin

Python

Remote

AWS S3 Connector MCP Server

A production-ready Model Context Protocol (MCP) server for AWS S3 Tables operations.

Provides 16 tools for comprehensive S3 Tables management:

Table bucket and namespace operations
Table CRUD and query operations
Metadata and maintenance management
Data import (CSV, Parquet, row append)

Supports three transport modes: stdio, SSE, and streamable-http.

Folder Structure

aws-s3-connector-tool/
|-- Dockerfile
|-- LICENSE
|-- mcp.example.json
|-- pyproject.toml
|-- README.md
|-- server.py
|-- tests/
|   |-- __init__.py
|   `-- test_s3_tools.py
`-- tools/
    |-- __init__.py
    |-- s3_connector_tools.py
    `-- toolhandler.py

Related MCP server: AWS S3 MCP Server

Available Tools (16)

Table Bucket Management

create_table_bucket - Create a new S3 table bucket
list_table_buckets - List all S3 table buckets

Namespace Management

create_namespace - Create a namespace in a table bucket
list_namespaces - List all namespaces

Table Operations

create_table - Create a new S3 table
list_tables - List all S3 tables
rename_table - Rename or move a table

Metadata Operations

get_table_metadata_location - Get table metadata S3 URI
update_table_metadata_location - Update table metadata location
get_bucket_metadata_config - Get metadata config for regular S3 bucket

Maintenance Operations

get_table_maintenance_config - Get table maintenance configuration
get_maintenance_job_status - Get maintenance job status

Data Operations

query_database - Execute SQL queries (requires PyIceberg/Daft)
append_rows_to_table - Append rows to table (requires PyIceberg)
import_csv_to_table - Import CSV data to table
import_parquet_to_table - Import Parquet data to table

Tools Reference

1. create_table_bucket

Creates an S3 table bucket.

Parameters:

name (required) - Name of the table bucket (3-63 chars, lowercase letters, numbers, hyphens only)
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:CreateTableBucket

Example:

{
  "name": "my-data-warehouse",
  "region_name": "us-west-2"
}

Returns:

{
  "status": "success",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse",
  "message": "Table bucket 'my-data-warehouse' created successfully in region us-west-2"
}

2. list_table_buckets

List all S3 table buckets for your AWS account.

Parameters:

region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:ListTableBuckets

Example:

{
  "region_name": "us-west-2"
}

Returns:

{
  "status": "success",
  "count": 2,
  "table_buckets": [
    {
      "name": "my-data-warehouse",
      "arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse",
      "createdAt": "2026-05-10T10:30:00Z"
    }
  ]
}

3. create_namespace

Creates a namespace in an S3 table bucket. A namespace is a logical grouping of tables.

Parameters:

namespace (required) - Namespace name (1-255 chars, alphanumeric, underscores, hyphens)
table_bucket_arn (required) - ARN of the table bucket
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:CreateNamespace

Example:

{
  "namespace": "retail_data",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse",
  "region_name": "us-west-2"
}

Returns:

{
  "status": "success",
  "namespace": "retail_data",
  "message": "Namespace 'retail_data' created successfully"
}

4. list_namespaces

List all namespaces across all S3 table buckets.

Parameters:

region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:ListNamespaces

Example:

{
  "region_name": "us-west-2"
}

Returns:

{
  "status": "success",
  "count": 3,
  "namespaces": [
    {
      "namespace": "retail_data",
      "tableBucketARN": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse"
    }
  ]
}

5. create_table

Creates a new S3 table in a namespace. Supports Iceberg format with customizable schema.

Parameters:

name (required) - Table name (1-255 chars, alphanumeric, underscores, hyphens)
namespace (required) - Namespace name
table_bucket_arn (required) - ARN of the table bucket
format (optional) - Table format (default: ICEBERG)
metadata (optional) - Table metadata as JSON string (includes schema definition)
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:CreateTable

Supported Iceberg Types: boolean, int, long, float, double, decimal(P,S), date, time, timestamp, timestamptz, string

Example:

{
  "name": "customers",
  "namespace": "retail_data",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse",
  "format": "ICEBERG",
  "metadata": "{\"iceberg\": {\"schema\": {\"type\": \"struct\", \"fields\": [{\"id\": 1, \"name\": \"customer_id\", \"type\": \"long\", \"required\": true}, {\"id\": 2, \"name\": \"customer_name\", \"type\": \"string\", \"required\": false}]}}}"
}

Returns:

{
  "status": "success",
  "table_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse/table/retail_data/customers",
  "version_token": "abc123...",
  "message": "Table 'customers' created successfully in namespace 'retail_data'"
}

6. list_tables

List all S3 tables across all table buckets and namespaces.

Parameters:

region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:ListTables

Example:

{
  "region_name": "us-west-2"
}

Returns:

{
  "status": "success",
  "count": 5,
  "tables": [
    {
      "name": "customers",
      "namespace": "retail_data",
      "tableBucketARN": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse",
      "arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse/table/retail_data/customers"
    }
  ]
}

7. rename_table

Renames an S3 table or moves it to a different namespace within the same table bucket.

Parameters:

name (required) - Current table name
namespace (required) - Current namespace
table_bucket_arn (required) - ARN of the table bucket
new_name (optional) - New table name
new_namespace_name (optional) - New namespace name
version_token (optional) - Version token for optimistic locking
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:RenameTable

Example:

{
  "name": "customers",
  "namespace": "retail_data",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse",
  "new_name": "customer_profiles",
  "new_namespace_name": "retail_data"
}

Returns:

{
  "status": "success",
  "message": "Table renamed successfully"
}

8. get_table_metadata_location

Gets the S3 URI location of the table metadata, which contains the schema and other configuration.

Parameters:

name (required) - Table name
namespace (required) - Namespace name
table_bucket_arn (required) - ARN of the table bucket
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:GetTableMetadataLocation

Example:

{
  "name": "customers",
  "namespace": "retail_data",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse"
}

Returns:

{
  "status": "success",
  "metadata_location": "s3://warehouse-location/metadata/00001-abc123.metadata.json",
  "warehouse_location": "s3://warehouse-location/"
}

9. update_table_metadata_location

Updates the metadata location for an S3 table. The metadata location must be an S3 URI within the table's warehouse location.

Parameters:

name (required) - Table name
namespace (required) - Namespace name
table_bucket_arn (required) - ARN of the table bucket
metadata_location (required) - New metadata location S3 URI (1-2048 chars)
version_token (required) - Version token for optimistic locking (1-2048 chars)
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:UpdateTableMetadataLocation

Example:

{
  "name": "customers",
  "namespace": "retail_data",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse",
  "metadata_location": "s3://warehouse-location/metadata/00002-def456.metadata.json",
  "version_token": "abc123..."
}

Returns:

{
  "status": "success",
  "message": "Table metadata location updated successfully"
}

10. get_bucket_metadata_config

Retrieves the metadata table configuration for a regular general-purpose S3 bucket. S3 Metadata automatically captures object metadata in read-only Apache Iceberg tables.

Parameters:

bucket (required) - Name of the S3 bucket
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3:GetBucketMetadataConfiguration

Metadata Table Schema Includes:

System-defined: bucket, key, size, last_modified_date, storage_class, e_tag, etc.
Custom metadata: object_tags, user_metadata
Event metadata: requester, source_ip_address, request_id

Example:

{
  "bucket": "my-general-purpose-bucket",
  "region_name": "us-west-2"
}

Returns:

{
  "status": "success",
  "s3_table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/metadata-bucket",
  "s3_table_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/metadata-bucket/table/...",
  "s3_table_name": "my-general-purpose-bucket-metadata",
  "s3_table_namespace": "s3_metadata"
}

11. get_table_maintenance_config

Gets details about the maintenance configuration of a table. S3 Tables maintenance includes compaction and optimization settings.

Parameters:

name (required) - Table name
namespace (required) - Namespace name
table_bucket_arn (required) - ARN of the table bucket
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:GetTableMaintenanceConfiguration

Example:

{
  "name": "customers",
  "namespace": "retail_data",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse"
}

Returns:

{
  "status": "success",
  "configuration": {
    "icebergCompaction": {
      "status": "ENABLED"
    }
  }
}

12. get_maintenance_job_status

Gets the status of a maintenance job for a table.

Parameters:

name (required) - Table name
namespace (required) - Namespace name
table_bucket_arn (required) - ARN of the table bucket
region_name (optional) - AWS region (default: us-west-2)

Required Permission: s3tables:GetTableMaintenanceJobStatus

Example:

{
  "name": "customers",
  "namespace": "retail_data",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-data-warehouse"
}

Returns:

{
  "status": "success",
  "job_status": "COMPLETED",
  "details": {
    "startTime": "2026-05-10T10:00:00Z",
    "endTime": "2026-05-10T10:05:00Z"
  }
}

13. query_database

Execute SQL queries against S3 Tables using PyIceberg/Daft engine. Provides read-only SQL query capabilities.

Parameters:

warehouse (required) - Warehouse ARN for Iceberg catalog
region (required) - AWS region for S3Tables/Iceberg REST endpoint
namespace (required) - Namespace name (1-255 chars)
uri (required) - REST URI for Iceberg catalog
query (optional) - SQL query (default: SELECT * FROM table LIMIT 10)
catalog_name (optional) - Catalog name
rest_signing_name (optional) - REST signing name (e.g., s3tables)
rest_sigv4_enabled (optional) - Enable SigV4 signing (true/false)

Dependencies: Requires pyiceberg and daft packages

Example:

{
  "warehouse": "arn:aws:s3tables:::bucket/my-data-warehouse",
  "region": "us-west-2",
  "namespace": "retail_data",
  "uri": "https://s3tables.us-west-2.amazonaws.com/iceberg",
  "query": "SELECT customer_id, customer_name FROM customers WHERE region = 'US' LIMIT 100",
  "catalog_name": "s3tablescatalog",
  "rest_signing_name": "s3tables",
  "rest_sigv4_enabled": "true"
}

Returns:

{
  "status": "success",
  "rows": [...],
  "row_count": 100
}

14. append_rows_to_table

Append rows to an Iceberg table using PyIceberg engine. Rows are provided as a list of dictionaries.

Parameters:

warehouse (required) - Warehouse ARN for Iceberg catalog
region (required) - AWS region
namespace (required) - Namespace name
table_name (required) - Table name
uri (required) - REST URI for Iceberg catalog
rows (required) - Array of row objects (dictionaries)
catalog_name (optional) - Catalog name
rest_signing_name (optional) - REST signing name
rest_sigv4_enabled (optional) - Enable SigV4 signing

Dependencies: Requires pyiceberg package

Required Permission: s3tables:PutTableData

Example:

{
  "warehouse": "arn:aws:s3tables:::bucket/my-data-warehouse",
  "region": "us-west-2",
  "namespace": "retail_data",
  "table_name": "customers",
  "uri": "https://s3tables.us-west-2.amazonaws.com/iceberg",
  "rows": [
    {"customer_id": 1001, "customer_name": "Alice Johnson"},
    {"customer_id": 1002, "customer_name": "Bob Smith"}
  ],
  "catalog_name": "s3tablescatalog",
  "rest_signing_name": "s3tables",
  "rest_sigv4_enabled": "true"
}

Returns:

{
  "status": "success",
  "rows_appended": 2,
  "message": "Successfully appended 2 rows to table"
}

15. import_csv_to_table

Import data from a CSV file stored in S3 into an S3 table. If the table doesn't exist, it will be created with inferred schema. If it exists, CSV schema must be compatible.

Parameters:

warehouse (required) - Warehouse ARN for Iceberg catalog
region (required) - AWS region
namespace (required) - Namespace name
table_name (required) - Table name
s3_url (required) - S3 URL of CSV file (format: s3://bucket-name/key)
uri (required) - REST URI for Iceberg catalog
catalog_name (optional) - Catalog name
preserve_case (optional) - Preserve column name case (default: false, converts to snake_case)
rest_signing_name (optional) - REST signing name
rest_sigv4_enabled (optional) - Enable SigV4 signing

Dependencies: Requires pyiceberg, pandas or daft, and pyarrow

Required Permissions:

s3:GetObject for the CSV file
s3tables:GetTable, s3tables:GetTables
s3tables:PutTableData

Example:

{
  "warehouse": "arn:aws:s3tables:::bucket/my-data-warehouse",
  "region": "us-west-2",
  "namespace": "retail_data",
  "table_name": "customers",
  "s3_url": "s3://my-data-bucket/imports/customers.csv",
  "uri": "https://s3tables.us-west-2.amazonaws.com/iceberg",
  "catalog_name": "s3tablescatalog",
  "preserve_case": false,
  "rest_signing_name": "s3tables",
  "rest_sigv4_enabled": "true"
}

Returns:

{
  "status": "success",
  "message": "Successfully imported 1,543 rows from customers.csv",
  "rows_processed": 1543,
  "file_processed": "customers.csv"
}

16. import_parquet_to_table

Import data from a Parquet file stored in S3 into an existing S3 table. The table must already exist and the Parquet schema must be compatible.

Parameters:

warehouse (required) - Warehouse ARN for Iceberg catalog
region (required) - AWS region
namespace (required) - Namespace name
table_name (required) - Table name (must exist)
s3_url (required) - S3 URL of Parquet file (format: s3://bucket-name/key)
uri (required) - REST URI for Iceberg catalog
catalog_name (optional) - Catalog name
preserve_case (optional) - Preserve column name case (default: false)
rest_signing_name (optional) - REST signing name
rest_sigv4_enabled (optional) - Enable SigV4 signing

Dependencies: Requires pyiceberg, pyarrow or daft

Required Permissions:

s3:GetObject for the Parquet file
s3tables:GetTable, s3tables:GetTables
s3tables:PutTableData

Example:

{
  "warehouse": "arn:aws:s3tables:::bucket/my-data-warehouse",
  "region": "us-west-2",
  "namespace": "retail_data",
  "table_name": "orders",
  "s3_url": "s3://my-data-bucket/imports/orders.parquet",
  "uri": "https://s3tables.us-west-2.amazonaws.com/iceberg",
  "catalog_name": "s3tablescatalog",
  "preserve_case": false,
  "rest_signing_name": "s3tables",
  "rest_sigv4_enabled": "true"
}

Returns:

{
  "status": "success",
  "message": "Successfully imported 8,234 rows from orders.parquet",
  "rows_processed": 8234,
  "file_processed": "orders.parquet"
}

Prerequisites

Python 3.10+
AWS credentials configured (via environment variables or AWS CLI)
Appropriate IAM permissions for S3 Tables operations

Installation

python -m venv .venv
# Windows
.venv\Scripts\activate
# macOS / Linux
source .venv/bin/activate

cd aws-s3-connector-tool

pip install -e .

Run

stdio (default for MCP desktop hosts)

aws-s3-connector-mcp --mode stdio

Or directly:

python server.py --mode stdio

SSE

aws-s3-connector-mcp --mode sse --host 0.0.0.0 --port 8000

Endpoints:

GET /sse
POST /messages/

Streamable HTTP

aws-s3-connector-mcp --mode streamable-http --host 0.0.0.0 --port 8000

Endpoint:

POST /mcp

Health endpoints:

GET /health
GET /healthz
GET /

Docker

# Build image
docker build -t aws-s3-connector-mcp .

# Run (streamable-http default)
docker run -p 8000:8000 \
  -e AWS_ACCESS_KEY_ID=your-key \
  -e AWS_SECRET_ACCESS_KEY=your-secret \
  -e AWS_REGION=us-west-2 \
  aws-s3-connector-mcp

AWS Credentials

The server uses boto3 to interact with AWS services. Configure credentials via:

Environment variables:
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- AWS_REGION (optional, defaults to us-west-2)
AWS CLI configuration (~/.aws/credentials)
IAM role (when running on EC2/ECS)

Required IAM Permissions

Minimum permissions for basic operations:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3tables:CreateTableBucket",
        "s3tables:ListTableBuckets",
        "s3tables:CreateNamespace",
        "s3tables:ListNamespaces",
        "s3tables:CreateTable",
        "s3tables:ListTables",
        "s3tables:GetTable",
        "s3tables:RenameTable",
        "s3tables:GetTableMetadataLocation",
        "s3tables:UpdateTableMetadataLocation",
        "s3tables:GetTableMaintenanceConfiguration",
        "s3tables:GetTableMaintenanceJobStatus",
        "s3tables:PutTableData",
        "s3:GetObject",
        "s3:GetBucketMetadataConfiguration"
      ],
      "Resource": "*"
    }
  ]
}

Example Usage

Create Table Bucket

{
  "name": "my-table-bucket",
  "region_name": "us-west-2"
}

Create Table

{
  "name": "customers",
  "namespace": "retail_data",
  "table_bucket_arn": "arn:aws:s3tables:us-west-2:123456789012:bucket/my-table-bucket",
  "format": "ICEBERG",
  "metadata": "{\"iceberg\": {\"schema\": {...}}}"
}

Query Database

{
  "warehouse": "arn:aws:s3tables:::bucket/my-table-bucket",
  "region": "us-west-2",
  "namespace": "retail_data",
  "uri": "https://s3tables.us-west-2.amazonaws.com/iceberg",
  "query": "SELECT * FROM customers LIMIT 10"
}

Advanced Features

Data Import Tools

The CSV and Parquet import tools require additional dependencies:

pyiceberg
pandas or daft
pyarrow

Install them separately:

pip install pyiceberg pandas pyarrow

Query Execution

The query_database tool requires PyIceberg and Daft for SQL execution against S3 Tables.

MCP Client Configuration

See mcp.example.json for sample client configuration. Update the cwd path to match your installation.

Testing

pip install -e .[dev]
pytest -v

Architecture

MCP Client (Claude/Cursor/VS Code)
    |
    | JSON-RPC 2.0
    v
Transport Layer (stdio | SSE | HTTP)   <- server.py
    |
    v
MCP Server callbacks (list_tools / call_tool)
    |
    v
ToolHandler Registry (16 tools)        <- server.py
    |
    v
AWS S3 Tables Tool Handlers            <- s3_connector_tools.py
    |
    v
boto3 (AWS SDK)
    |
    v
AWS S3 Tables API

Troubleshooting

boto3 not found

pip install boto3

AWS credentials not configured

aws configure
# or set environment variables
export AWS_ACCESS_KEY_ID=your-key
export AWS_SECRET_ACCESS_KEY=your-secret
export AWS_REGION=us-west-2

Permission denied errors

Verify IAM permissions include all required s3tables actions.

License

MIT License - see LICENSE file for details.

Available Tools

17 tools

append_rows_to_tableAppend Rows to TableB

Append rows to an Iceberg table using PyIceberg engine. The rows parameter must be a list of dictionaries, each representing a row.

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	REST URI for Iceberg catalog
`rows`	Yes	List of rows to append, each as a dict
`region`	Yes	AWS region for S3Tables/Iceberg REST endpoint
`namespace`	Yes	The namespace. Must be 1-255 characters long.
`warehouse`	Yes	Warehouse string for Iceberg catalog
`table_name`	Yes	The table name. Must be 1-255 characters long.
`catalog_name`	No	Catalog name
`rest_signing_name`	No	REST signing name
`rest_sigv4_enabled`	No	Enable SigV4 signing

TDQS

B3.3/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 fully disclose behavior. It only mentions the engine and row format. It does not describe whether the operation is idempotent, if it handles partitioning, error handling, or performance characteristics. For a mutation tool, this omission is significant.

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?

Two sentences with no fluff. First sentence states purpose, second clarifies the rows parameter. Could be improved by structuring info into short paragraphs or bullet points for readability, but currently efficient.

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?

The tool has 9 parameters (6 required) and no output schema. Description lacks practical context like success/failure behavior, typical use cases, or how to verify the append. For a complex tool with many parameters, this is insufficient for an agent to use confidently.

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 parameters are already well-described structurally. The description adds that rows must be a list of dicts, each representing a row, which is already implied by the schema type (array of objects). Minimal added value over schema descriptions.

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 (Append rows) and the resource (Iceberg table using PyIceberg engine). It distinguishes from sibling tools like create_table or import_csv_to_table by specifying direct row appending.

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 does not explicitly state when to use this tool vs alternatives like import_csv_to_table or import_parquet_to_table. It implies usage when data is already in a list of dictionaries, but lacks explicit guidance on prerequisites or when not to use.

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

connect_awsConnect to AWSA

Connect to AWS S3. Supports two modes:

Credentials mode (private buckets): provide aws_access_key_id + aws_secret_access_key + region_name.
Public S3 mode (no credentials): provide account_id + s3_bucket_url. Region is auto-detected from the URL when possible.

ParametersJSON Schema

Name	Required	Description
`account_id`	No	AWS Account ID (12-digit). Used in public S3 mode to identify the account.
`region_name`	No	AWS region (e.g. us-east-1). Auto-detected from s3_bucket_url if not provided.
`s3_bucket_url`	No	Public S3 bucket URL. Accepted formats: s3://bucket-name, https://bucket.s3.amazonaws.com, https://bucket.s3.REGION.amazonaws.com
`aws_access_key_id`	No	AWS Access Key ID (credentials mode)
`aws_session_token`	No	AWS Session Token for temporary/SSO credentials (credentials mode, optional)
`aws_secret_access_key`	No	AWS Secret Access Key (credentials mode)

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses the two connection modes and auto-detection behavior. However, it does not specify what the tool returns or what state changes occur (e.g., session creation).

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 concise, uses a bulleted list effectively, and has no unnecessary words. Every sentence adds meaning.

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 the moderate complexity and full schema coverage, the description covers the main use cases well. It omits what happens after connection (e.g., client object or session), which would improve completeness.

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

Parameters5/5

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

Schema coverage is 100%, and the description adds significant value by grouping parameters by mode and explaining auto-detection and URL formats. This organizes the information beyond the raw schema.

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 title and description explicitly state 'Connect to AWS S3' and distinguish between two modes (credentials and public S3). This differentiates it from sibling tools that deal with tables, namespaces, and metadata.

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 clearly explains when to use each mode (private buckets vs. public S3) and mentions auto-detection of region. It provides sufficient context, though it lacks explicit 'when not to use' or alternatives.

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

create_namespaceCreate NamespaceA

Creates a namespace. A namespace is a logical grouping of tables within your S3 table bucket. Permissions: You must have the s3tables:CreateNamespace permission.

ParametersJSON Schema

Name	Required	Description
`namespace`	Yes	The name of the namespace. Must be 1-255 characters long and contain only alphanumeric characters, underscores, and hyphens.
`region_name`	No	The AWS region name where the operation should be performed.
`table_bucket_arn`	Yes	Table bucket ARN

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, description carries full burden. It discloses required permission (s3tables:CreateNamespace), but fails to mention idempotency, failure modes (e.g., if namespace exists), or any side effects beyond creation.

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, front-loaded with the tool's purpose, then adds context. Every sentence earns its place with no fluff.

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?

No output schema, so description should hint at return value. It does not. Missing details on error conditions, idempotency, or namespace constraints beyond schema. 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 baseline is 3. The description adds minimal value beyond schema: it explains the namespace concept but does not elaborate on parameters (e.g., namespace format or region format) beyond what the schema already provides.

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 'Creates a namespace' and explains what a namespace is (logical grouping of tables). This distinguishes it from sibling tools like create_table_bucket (creates bucket) and create_table (creates table).

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?

No guidance on when to use this tool versus alternatives. It only mentions a required permission, but does not specify contexts or exclusions relative to siblings.

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

create_tableCreate S3 TableB

Creates a new S3 table associated with the given S3 namespace in an S3 table bucket. The S3 table can be configured with specific format and metadata settings. Permissions: You must have the s3tables:CreateTable permission.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The name of the table. Must be 1-255 characters long and contain only alphanumeric characters, underscores, and hyphens.
`format`	No	The format for the S3 table.
`metadata`	No	The metadata for the S3 table (JSON string).
`namespace`	Yes	The name of the namespace. Must be 1-255 characters long and contain only alphanumeric characters, underscores, and hyphens.
`region_name`	No	The AWS region name where the operation should be performed.
`table_bucket_arn`	Yes	Table bucket ARN

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description only mentions permissions. Does not disclose idempotency, side effects, error behavior, or whether table creation is immediate or asynchronous.

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?

Two well-structured sentences. Concise but not overly brief; permissions are noted separately. No redundant information.

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?

For a creation tool with 6 parameters and no output schema, description lacks return value info (e.g., table ARN), behavioral details, and guidance on prerequisites or failure modes.

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% with descriptions for all 6 parameters. Description adds no new meaning beyond restating 'format and metadata settings.' Baseline 3 is appropriate.

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?

Description clearly states 'Creates a new S3 table' and specifies association with namespace and bucket, with configurable settings. Distinct from sibling tools like create_table_bucket and create_namespace.

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?

No guidance on when to use this tool versus siblings such as rename_table, append_rows, or import_csv. Missing context for prerequisites (e.g., existing bucket/namespace) or typical use cases.

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

create_table_bucketCreate S3 Table BucketC

Creates an S3 table bucket. Permissions: You must have the s3tables:CreateTableBucket permission.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Name of the table bucket to create. Must be 3-63 characters long and contain only lowercase letters, numbers, and hyphens.
`region_name`	No	The AWS region name where the operation should be performed.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description only states a permission requirement. It does not disclose side effects, error handling, idempotency, or what happens if the bucket already exists. For a creation tool, this is insufficient.

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 with no unnecessary information. It is concise and to the point.

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?

The tool is simple (2 params, no output schema), but the description lacks context: no explanation of what a table bucket is, naming rules beyond schema, or what happens after creation. It feels incomplete.

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% with detailed parameter descriptions (name length, region_name). The description adds no parameter information beyond the schema, but the schema already covers semantics adequately.

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

Purpose4/5

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

The description clearly states the action (creates) and resource (S3 table bucket). It distinguishes from sibling tools like create_table and create_namespace, but could be enhanced with a brief explanation of what a table bucket is.

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?

No guidance on when to use this tool versus alternatives (e.g., create_table, list_table_buckets). Only a permission requirement is mentioned, but no context on prerequisites or use cases.

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

get_bucket_metadata_configGet Bucket Metadata ConfigC

Retrieves the metadata table configuration for a regular general purpose bucket in S3. Permissions: You must have the s3:GetBucketMetadataConfiguration permission.

ParametersJSON Schema

Name	Required	Description	Default
`bucket`	Yes	The name of the S3 bucket to get metadata table configuration for.
`region_name`	No	The AWS region name where the operation should be performed.

TDQS

C2.9/5.0

Behavior2/5

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

Without annotations, the description must disclose behavioral traits. It mentions the required permission but does not describe side effects, error conditions, rate limits, or return format. The behavioral profile is minimal, leaving the agent uncertain about what happens on success or failure.

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 very concise with two sentences, no unnecessary words, and front-loads the purpose. However, it lacks structural elements like bullet points or section breaks that could improve scannability for the agent.

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 100% schema coverage and no output schema, the description should explain what the function returns or any important behavior. It does not mention the return value structure, possible errors, or how the configuration is presented. This leaves the agent with incomplete context for using the tool effectively.

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 documents both parameters. The description adds no extra meaning beyond the schema's descriptions; it only restates the permission. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding.

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

Purpose4/5

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

The description clearly states the verb 'retrieves' and the resource 'metadata table configuration for a regular general purpose bucket in S3', making the tool's purpose specific and understandable. However, it does not explicitly distinguish this tool from sibling tools like 'get_table_metadata_location', which might cause confusion.

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?

The description provides a permission requirement but offers no guidance on when to use this tool versus alternatives, such as when to use get_table_metadata_location or get_table_maintenance_config. There is no 'when-not-to-use' advice or context about prerequisites.

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

get_maintenance_job_statusGet Maintenance Job StatusB

Gets the status of a maintenance job for a table. Permissions: You must have the s3tables:GetTableMaintenanceJobStatus permission.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The name of the table. Must be 1-255 characters long.
`namespace`	Yes	The name of the namespace. Must be 1-255 characters long.
`region_name`	No	The AWS region name where the operation should be performed.
`table_bucket_arn`	Yes	Table bucket ARN

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. Description only states it's a read operation and lists a permission, but does not disclose what happens if the job does not exist, rate limits, or any side effects.

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 concise sentences: one functional statement and one permission requirement. No redundant information.

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?

No output schema and no description of the return value. For a status tool, the output structure should be explained so the agent knows what to expect.

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% with minimal descriptions. The tool description adds only a permission note, not any additional parameter meaning. Baseline 3 is appropriate.

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?

Clearly states the action 'gets' and the object 'status of a maintenance job for a table'. Differentiates from sibling tools which involve creation, listing, or data operations.

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?

No guidance on when to use this tool versus alternatives. Only mentions required permission, but no context about prerequisites or scenarios.

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

get_table_maintenance_configGet Table Maintenance ConfigA

Gets details about the maintenance configuration of a table. Permissions: You must have the s3tables:GetTableMaintenanceConfiguration permission.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The name of the table. Must be 1-255 characters long.
`namespace`	Yes	The name of the namespace. Must be 1-255 characters long.
`region_name`	No	The AWS region name where the operation should be performed.
`table_bucket_arn`	Yes	Table bucket ARN

TDQS

A3.5/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. It mentions the required permission, which is helpful, but does not explicitly state whether the operation is read-only or if there are side effects. The description implies a read operation but lacks explicit safety disclosure.

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 extremely concise with two sentences: one stating the purpose and one stating the required permission. No unnecessary words or redundancy.

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?

Given no output schema and no annotations, the description is minimal. It covers the purpose and permission but lacks detail on what the maintenance configuration includes or what the response looks like. Adequate but could be more complete.

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?

The schema has 100% description coverage for all parameters, so the description adds no additional parameter meaning. The description only mentions a permission, not parameter details. Baseline score of 3 is appropriate given high schema coverage.

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 'Gets details about the maintenance configuration of a table' with a specific verb and resource. The tool name is self-explanatory, and it distinguishes itself from sibling tools like get_maintenance_job_status and get_table_metadata_location by focusing on maintenance configuration.

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?

The description lacks guidance on when to use this tool versus alternatives. It only mentions a required permission but does not provide context on when this tool is appropriate or when to use other maintenance-related tools.

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

get_table_metadata_locationGet Table Metadata LocationB

Gets the S3 URI location of the table metadata, which contains the schema and other table configuration information. Permissions: You must have the s3tables:GetTableMetadataLocation permission.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The name of the table. Must be 1-255 characters long.
`namespace`	Yes	The name of the namespace. Must be 1-255 characters long.
`region_name`	No	The AWS region name where the operation should be performed.
`table_bucket_arn`	Yes	Table bucket ARN

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It mentions a required permission but does not state whether the operation is read-only, idempotent, or has side effects. The tool likely reads metadata, but this is not explicitly stated.

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 with no extraneous information. The purpose is stated first, followed by permission requirement. Front-loaded and efficient.

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?

Given no output schema, the description does not explain the return format (e.g., just the S3 URI or full metadata). It mentions 'S3 URI location' but lacks detail on response structure. For a simple retrieval, this is adequate but could be more complete.

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 baseline is 3. The description adds that the metadata contains schema and configuration but does not add specific meaning to individual parameters beyond what the schema already provides.

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 'Gets the S3 URI location of the table metadata', which distinguishes it from siblings like 'update_table_metadata_location' and 'get_bucket_metadata_config'. The verb 'Gets' and resource 'S3 URI location of the table metadata' are specific.

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?

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of prerequisites, context, or when not to use it. Siblings like 'update_table_metadata_location' exist but no comparison is provided.

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

import_csv_to_tableImport CSV to TableB

Reads data from a CSV file stored in S3 and imports it into an S3 table. If the table doesn't exist, it will be created with a schema inferred from the CSV.

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	REST URI for Iceberg catalog
`region`	Yes	AWS region for S3Tables/Iceberg REST endpoint
`s3_url`	Yes	The S3 URL of the CSV file (format: s3://bucket-name/key)
`namespace`	Yes	The namespace. Must be 1-255 characters long.
`warehouse`	Yes	Warehouse string for Iceberg catalog
`table_name`	Yes	The table name. Must be 1-255 characters long.
`catalog_name`	No	Catalog name
`preserve_case`	No	Preserve case of column names
`rest_signing_name`	No	REST signing name
`rest_sigv4_enabled`	No	Enable SigV4 signing

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses schema inference on creation but omits whether data is appended or replaced if table exists. Adequate but incomplete.

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 concise sentences, front-loaded with action, no redundancy.

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?

For a tool with 10 parameters and no output schema, the description is too brief. Missing return info, behavior on existing tables, and handling of CSV format specifics.

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 baseline is 3. Description adds no extra detail about parameters like preserve_case or catalog_name beyond their schema descriptions.

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 imports CSV from S3 into an S3 table and creates the table with inferred schema if missing. This is a specific verb+resource description that distinguishes from siblings like import_parquet_to_table.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., import_parquet_to_table, append_rows_to_table). No prerequisites or conditions mentioned.

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

import_parquet_to_tableImport Parquet to TableA

Reads data from a Parquet file stored in S3 and imports it into an existing S3 table. The table must already exist. The Parquet file schema must be compatible with the table's schema.

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	REST URI for Iceberg catalog
`region`	Yes	AWS region for S3Tables/Iceberg REST endpoint
`s3_url`	Yes	The S3 URL of the Parquet file (format: s3://bucket-name/key)
`namespace`	Yes	The namespace. Must be 1-255 characters long.
`warehouse`	Yes	Warehouse string for Iceberg catalog
`table_name`	Yes	The table name. Must be 1-255 characters long.
`catalog_name`	No	Catalog name
`preserve_case`	No	Preserve case of column names
`rest_signing_name`	No	REST signing name
`rest_sigv4_enabled`	No	Enable SigV4 signing

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses that it reads from S3, imports into existing table, and requires schema compatibility. However, it omits details on failure behavior, idempotency, permissions, or whether data is appended or replaced. Adequate but lacks depth.

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, front-loaded with the action. No redundant words. Every sentence adds value: first the action, then prerequisites.

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?

No output schema, so description should clarify return value (e.g., success, row count). It doesn't. With 10 parameters, description is brief and doesn't explain parameter interplay. Sibling tools are not contrasted. However, core flow is sufficiently covered.

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?

Input schema has 100% description coverage, providing baseline of 3. Description adds no parameter-specific semantics beyond the schema.

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?

Description clearly states it imports Parquet data into an existing S3 table, with specific verb 'imports' and resource 'S3 table'. It distinguishes from siblings like import_csv_to_table (CSV) and create_table (table creation) by specifying Parquet and existing table requirement.

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?

Description provides usage context: table must exist and schema compatibility required. It implicitly differentiates from CSV import, but does not explicitly mention when to use alternatives. No exclusions or alternative tool names are given.

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

list_namespacesList NamespacesA

List all namespaces across all S3 table buckets. Permissions: You must have the s3tables:ListNamespaces permission.

ParametersJSON Schema

Name	Required	Description	Default
`region_name`	No	The AWS region name where the operation should be performed.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It adds the permission requirement and implies a read-only operation, but does not disclose pagination, rate limits, or other behavioral traits beyond listing.

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 concise sentences: first for purpose, second for permission. No wasted words, efficiently front-loaded.

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?

For a simple list tool, the description covers purpose and permission. It could mention return format or pagination, but the tool is adequately specified without output schema.

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%, so the schema already documents the parameter. The description adds no additional meaning for the parameter, meeting the baseline expectation.

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 (List) and resource (namespaces) with scope 'across all S3 table buckets', distinguishing it from sibling tools like create_namespace.

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 provides a required permission but lacks explicit guidance on when to use this tool versus alternatives or when not to use it.

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

list_table_bucketsList S3 Table BucketsA

List all S3 table buckets for your AWS account. Permissions: You must have the s3tables:ListTableBuckets permission.

ParametersJSON Schema

Name	Required	Description	Default
`region_name`	No	The AWS region name where the operation should be performed.

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the permission requirement but lacks details on pagination, response format, or limits. For a simple list operation it is adequate but not comprehensive.

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 two sentences: first states purpose, second states permission. No redundant words, well-structured, and front-loaded.

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?

Given no output schema, the description should indicate what is returned (e.g., list of bucket names) but does not. It misses pagination handling and other runtime details, though it covers the basic purpose and permission.

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?

The single parameter region_name is fully described in the schema (100% coverage). The description does not add any additional meaning beyond the schema, so baseline score of 3 is appropriate.

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?

Description states 'List all S3 table buckets for your AWS account' which clearly defines the action and resource. It distinguishes this from sibling tools like list_tables (which lists tables within a bucket) and list_namespaces.

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 mentions a required permission but does not provide guidance on when to use this tool versus alternatives. It is implied for listing table buckets, but no explicit exclusions or context for using other tools.

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

list_tablesList S3 TablesA

List all S3 tables across all table buckets and namespaces. Permissions: You must have the s3tables:ListTables permission.

ParametersJSON Schema

Name	Required	Description	Default
`region_name`	No	The AWS region name where the operation should be performed.

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the permission requirement and scope (all tables across all buckets/namespaces), but omits details like pagination, result format, or potential size limits. It is not contradictory to any annotations (none exist).

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 comprises two short sentences: one for action and one for permissions. It is front-loaded and contains no superfluous words, earning high marks for conciseness.

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 output schema and annotations, the description should provide more context about the return value (e.g., list of table names, bucket/namespace structure) and any limitations. The current description is too sparse to fully inform an agent.

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?

The input schema has 100% description coverage for the single parameter (region_name). The tool description does not add any extra meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 'List all S3 tables across all table buckets and namespaces,' specifying a specific verb and resource. This directly distinguishes it from sibling tools like create_table or list_namespaces.

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 mentions the required permission (s3tables:ListTables), providing necessary context. However, it does not explicitly state when to use this tool over alternatives, such as when a filtered or scoped listing is needed, nor does it offer any when-not-to-use guidance.

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

query_databaseQuery S3 Tables DatabaseA

Execute SQL queries against S3 Tables using PyIceberg/Daft engine. This tool provides a secure interface to run read-only SQL queries.

ParametersJSON Schema

Name	Required	Description
`uri`	Yes	REST URI for Iceberg catalog
`query`	No	Optional SQL query. If not provided, will execute SELECT * FROM table.
`region`	Yes	AWS region for S3Tables/Iceberg REST endpoint
`namespace`	Yes	The namespace. Must be 1-255 characters long.
`warehouse`	Yes	Warehouse string for Iceberg catalog
`catalog_name`	No	Catalog name
`rest_signing_name`	No	REST signing name
`rest_sigv4_enabled`	No	Enable SigV4 signing

TDQS

A3.6/5.0

Behavior3/5

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

The description discloses that queries are read-only and secure, and mentions a default behavior (SELECT * FROM table when no query given). With no annotations provided, the description carries the burden, but it lacks details on error handling, performance, or parameter effects.

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 two sentences, front-loading the core purpose and then adding the read-only and secure aspect. Every word is meaningful and no redundancy.

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 tool's complexity (8 parameters, no output schema), the description is too brief. It omits any mention of return format, limits, or parameter relationships, which is needed for effective use.

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?

The input schema has 100% description coverage for all parameters, so the description does not need to add much. It does not provide extra context beyond the schema, which meets the baseline but does not excel.

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 identifies the verb (Execute SQL queries), resource (S3 Tables), and scope (read-only). This differentiates it from sibling write tools like create_table or import_csv_to_table.

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 states it is 'read-only SQL queries', implying it should be used for querying rather than modifying data. However, it does not explicitly mention when not to use it or suggest alternatives among the many sibling tools.

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

rename_tableRename S3 TableA

Renames an S3 table or moves it to a different S3 namespace within the same S3 table bucket. Permissions: You must have the s3tables:RenameTable permission.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The current name of the table. Must be 1-255 characters long.
`new_name`	No	The new name of the table. Must be 1-255 characters long.
`namespace`	Yes	The current namespace. Must be 1-255 characters long.
`region_name`	No	The AWS region name where the operation should be performed.
`version_token`	No	The version token of the S3 table. Must be 1-2048 characters long.
`table_bucket_arn`	Yes	Table bucket ARN
`new_namespace_name`	No	The new namespace. Must be 1-255 characters long.

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It adds permission info (s3tables:RenameTable) but lacks details about side effects, atomicity, or behavior if new name exists. Adequate but 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 concise sentences: purpose first, then permissions. No unnecessary text, front-loaded with key action.

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 7 parameters (many optional), no output schema, and a rename operation that could affect references, the description is too brief. It omits the role of version_token, the implication of new_namespace_name, and whether the move is synchronous or has constraints.

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%, so the schema already documents all parameters. The description adds no additional parameter-level meaning beyond what the schema provides.

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?

Description clearly states 'Renames an S3 table or moves it to a different S3 namespace within the same S3 table bucket.' It uses a specific verb and resource, and distinguishes it from sibling tools that create or list tables.

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 only mentions required permissions but does not provide when or when not to use this tool, nor does it reference alternative tools for similar operations. Usage is implied but not explicitly guided.

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

update_table_metadata_locationUpdate Table Metadata LocationB

Updates the metadata location for an S3 table. Permissions: You must have the s3tables:UpdateTableMetadataLocation permission.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The name of the table. Must be 1-255 characters long.
`namespace`	Yes	The name of the namespace. Must be 1-255 characters long.
`region_name`	No	The AWS region name where the operation should be performed.
`version_token`	Yes	The version token of the S3 table. Must be 1-2048 characters long.
`table_bucket_arn`	Yes	Table bucket ARN
`metadata_location`	Yes	The new metadata location for the S3 table. Must be 1-2048 characters long.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It mentions the required permission but does not disclose side effects, error conditions, or whether the operation is destructive.

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 clear purpose: action and permission. No wasted words.

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?

Minimal context for a mutation tool with 6 parameters and no output schema; lacks details on return values, error handling, or prerequisites like version token usage.

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 description does not need to elaborate. It adds no parameter-specific information beyond what the schema provides.

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 explicitly states the action ('Updates the metadata location') and the target resource ('S3 table'), distinguishing it from siblings like get_table_metadata_location.

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?

No guidance on when to use this tool versus alternatives (e.g., create_table, rename_table) or any prerequisites beyond permission.

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.

17 tool updatesv1.0.0Jul 28, 2026
- First observedappend_rows_to_table
- First observedconnect_aws
- First observedcreate_namespace
- First observedcreate_table
- First observedcreate_table_bucket
- First observedget_bucket_metadata_config
- First observedget_maintenance_job_status
- First observedget_table_maintenance_config
- First observedget_table_metadata_location
- First observedimport_csv_to_table
- First observedimport_parquet_to_table
- First observedlist_namespaces
- First observedlist_table_buckets
- First observedlist_tables
- First observedquery_database
- First observedrename_table
- First observedupdate_table_metadata_location

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-07-28 10:20 across 17 tools

Disambiguation5/5

Each tool targets a distinct operation on S3 Tables or related resources (e.g., bucket creation, namespace management, table CRUD, metadata, maintenance, data import/query, and connection setup). There is no overlap between tool purposes.

Naming Consistency5/5

All tools follow a clear verb_noun (or verb_noun_noun) pattern, e.g., create_table_bucket, list_namespaces, get_table_metadata_location. No mixing of conventions like camelCase or inconsistent verb forms.

Tool Count4/5

17 tools cover a broad domain of S3 Tables management, data operations, and connectivity. While slightly above the typical 3-15 range, they are well-scoped for the server's stated purpose.

Completeness2/5

Missing essential CRUD operations like delete (table, namespace, table bucket) and update (except metadata location). No tool to retrieve table schema or detailed table info beyond metadata location. Significant lifecycle gaps exist.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Supabase B
io.github.mcp-dir
Your Supabase account in natural language: run SQL, apply migrations, manage tables, storage, edge f
Databases Cloud Platforms
351
OleanderOAuth
dev.oleander
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
Databases Data Platforms Data Visualization
2
Databricks B
io.github.mcp-dir
Your Databricks Lakehouse in natural language: run SQL on your SQL warehouses, track long-running qu
Data Platforms Databases
171
ContextfloOAuth
com.contextflo
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Databases Security
1

Related MCP Servers

S3 MCP Server
Cloud Storage Cloud Platforms File Systems
AM1010101
A
license
A
quality
D
maintenance
Enables interaction with S3-compatible storage services like AWS S3 and Cloudflare R2, supporting bucket management, object listing, reading, uploading, and deletion operations.
Updated 9 months ago (2025-12-19 01:34 UTC)
5
199 npm
ISC
AWS S3 MCP Server
Cloud Platforms Cloud Storage
gangadharrr
A
license
Not graded
quality
C
maintenance
Enables interaction with AWS S3 storage through bucket operations (create, delete, list), object management (upload, download, delete, list), and bucket policy configuration using AWS credentials.
Updated 7 months ago (2026-02-21 12:00 UTC)
21 npm
2
MIT
S3 Data Lake MCP Server
Cloud Storage Databases Search
anespo
A
license
Not graded
quality
C
maintenance
Enables AI agents to query S3 data lakes using natural language, with support for CSV, JSON, Parquet and tools for data discovery, analysis, and metadata exploration.
Updated 8 months ago (2026-01-02 18:42 UTC)
1
MIT
nocodb-mcp-server
Databases Data Platforms
edwinbernadus
A
license
Not graded
quality
F
maintenance
Enables CRUD operations on NocoDB tables via natural language commands, supporting table manipulation, file upload, and bulk actions.
Updated 6 months ago (2026-03-30 13:44 UTC)
72 npm
75
MIT