AWS DynamoDB MCP Server

公式

Amazon DynamoDBの公式デベロッパーエクスペリエンスMCPサーバーです。このサーバーは、DynamoDBのエキスパートによる設計ガイダンスとデータモデリング支援を提供します。

ドキュメント

AWS DynamoDB MCP サーバー

Amazon DynamoDB 向けの公式開発者体験 MCP サーバーです。このサーバーは、DynamoDB の専門的な設計ガイダンスとデータモデリング支援を提供します。

[!IMPORTANT] 生成 AI は誤りを起こす可能性があります。選択した AI モデルやエージェント型コーディングアシスタントが生成するすべての出力を確認することを検討してください。AWS 責任ある AI ポリシーを参照してください。

利用可能なツール

DynamoDB MCP サーバーは、データモデリング、検証、コスト分析、コード生成のための 8 つのツールを提供します。

dynamodb_data_modeling - エンタープライズレベルの設計パターン、コスト最適化戦略、マルチテーブル設計哲学を含む完全な DynamoDB データモデリングエキスパートプロンプトを取得します。要件収集、アクセスパターン分析、スキーマ設計をガイドします。

呼び出し例: 「DynamoDB データモデリング MCP サーバーを使用して、e コマースアプリケーションのデータモデルを設計する」
dynamodb_data_model_validation - dynamodb_data_model.json を読み込み、DynamoDB Local をセットアップし、テストデータを含むテーブルを作成し、定義されたすべてのアクセスパターンを実行することで、DynamoDB データモデルを検証します。詳細な検証結果を dynamodb_model_validation.json に保存します。

呼び出し例: 「DynamoDB データモデルを検証する」
source_db_analyzer - 既存のデータベース (MySQL、PostgreSQL、SQL Server、Oracle) を分析してスキーマ構造とアクセスパターンを抽出し、dynamodb_data_modeling で使用するためのタイムスタンプ付き分析ファイルを生成します。MySQL 向けの RDS Data API ベースのアクセスと接続ベースのアクセスの両方をサポートします。

呼び出し例: 「MySQL データベースを分析し、DynamoDB データモデルの設計を支援する」
generate_resources - DynamoDB データモデル JSON ファイル (dynamodb_data_model.json) からさまざまなリソースを生成します。現在サポートされているのは cdk リソースタイプのみです。cdk を resource_type パラメータとして渡すと、DynamoDB テーブルをデプロイする CDK アプリが生成されます。CDK アプリは dynamodb_data_model.json を読み取り、適切な設定でテーブルを作成します。

呼び出し例: 「CDK を使用して DynamoDB データモデルをデプロイするためのリソースを生成する」
dynamodb_data_model_schema_converter - データモデル (dynamodb_data_model.md) を、DynamoDB テーブル、インデックス、エンティティ、フィールド、アクセスパターンを表す構造化された schema.json ファイルに変換します。この機械可読形式はコード生成に使用され、ドキュメント生成やインフラストラクチャプロビジョニングなどの他の目的にも拡張できます。最大 8 回の反復でスキーマを自動的に検証し、正確性を確保します。

呼び出し例: 「コード生成のためにデータモデルを schema.json に変換する」
dynamodb_data_model_schema_validator - コード生成の互換性のために schema.json ファイルを検証します。フィールドタイプ、操作、GSI マッピング、パターン ID をチェックし、修正提案付きの詳細なエラーメッセージを提供します。generate_data_access_layer ツールでスキーマを使用できる状態にします。

呼び出し例: 「/path/to/schema.json にある schema.json ファイルを検証する」
generate_data_access_layer - schema.json から型安全な Python コードを生成します。フィールド検証付きのエンティティクラス、CRUD 操作付きのリポジトリクラス、完全に実装されたアクセスパターン、オプションの使用例が含まれます。生成されたコードは、検証に Pydantic を、DynamoDB 操作に boto3 を使用します。

呼び出し例: 「schema.json から Python コードを生成する」
compute_performances_and_costs - アクセスパターンから DynamoDB のキャパシティユニット (RCU/WCU) と月額コストを計算します。すべての DynamoDB 操作 (GetItem、Query、Scan、PutItem、UpdateItem、DeleteItem、BatchGetItem、BatchWriteItem、TransactGetItems、TransactWriteItems) を分析し、GSI の追加書き込みを追跡し、ストレージコストを計算します。包括的なコストレポートを dynamodb_data_model.md に追加します。

呼び出し例: 「DynamoDB データモデルのコストとパフォーマンスを計算する」

前提条件

Astral または GitHub README から uv をインストールします
uv python install 3.10 を使用して Python をインストールします
AWS サービスにアクセスできる AWS 認証情報を設定します

インストール

Kiro	Cursor	VS Code

注意: 上記のインストールボタンは、デフォルトで AWS_REGION を us-west-2 に設定します。異なるリージョンが必要な場合は、インストール後に MCP 設定でこの値を更新してください。

MCP サーバーを設定ファイルに追加します (Kiro の場合は .kiro/settings/mcp.json に追加します - 設定パスを参照):

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Windows インストール

Windows ユーザーの場合、MCP サーバー設定の形式は若干異なります。

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "disabled": false,
      "timeout": 60,
      "type": "stdio",
      "command": "uv",
      "args": [
        "tool",
        "run",
        "--from",
        "awslabs.dynamodb-mcp-server@latest",
        "awslabs.dynamodb-mcp-server.exe"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

Docker インストール

docker build -t awslabs/dynamodb-mcp-server . が成功した後:

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--env",
        "FASTMCP_LOG_LEVEL=ERROR",
        "awslabs/dynamodb-mcp-server:latest"
      ],
      "env": {},
      "disabled": false,
      "autoApprove": []
    }
  }
}

データモデリング

自然言語によるデータモデリング

dynamodb_data_modeling ツールを使用して、AI エージェントとの自然言語による会話を通じて DynamoDB データモデルを設計します。「DynamoDB MCP を使用して DynamoDB データモデルを設計するのを手伝ってください」と依頼するだけです。

このツールは、アプリケーション要件を DynamoDB データモデルに変換する構造化されたワークフローを提供します。

要件収集フェーズ:

自然言語による会話を通じてアクセスパターンを取得します
エンティティ、リレーションシップ、読み取り/書き込みパターンを文書化します
各パターンの推定リクエスト/秒 (RPS) を記録します
リアルタイムで更新される dynamodb_requirements.md ファイルを作成します
他の AWS サービスに適したパターンを特定します (テキスト検索には OpenSearch、分析には Redshift)
特別な設計上の考慮事項にフラグを付けます (例: DynamoDB Streams と Lambda を必要とする大規模なファンアウトパターン)

設計フェーズ:

最適化されたテーブルとインデックスの設計を生成します
詳細な設計根拠を含む dynamodb_data_model.md を作成します
推定月額コストを提供します
各アクセスパターンがどのようにサポートされるかを文書化します
スケールとパフォーマンスに関する最適化の推奨事項を含みます

このツールは、推論モデルが高度なモデリング手法をガイドするのに役立つ、専門家が設計したコンテキストに支えられています。最良の結果は、Anthropic Claude 4/4.5 Sonnet、OpenAI o3、Google Gemini 2.5 などの推論対応モデルで得られます。

データモデル検証

データモデル検証の前提条件: データモデル検証ツールを使用するには、次のいずれかが必要です。

コンテナランタイム: Docker、Podman、Finch、または nerdctl (実行中のデーモン付き)
Java ランタイム: Java JRE バージョン 17 以降 (JAVA_HOME を設定するか、java がシステム PATH にあることを確認してください)

データモデル設計が完了したら、dynamodb_data_model_validation ツールを使用して、DynamoDB Local に対してデータモデルを自動的にテストします。検証ツールは、反復的な検証サイクルを作成することで、生成と実行の間のループを閉じます。

仕組み:

このツールは、従来の手動検証プロセスを自動化します。

セットアップ: DynamoDB Local 環境を起動します (Docker/Podman/Finch/nerdctl または Java フォールバック)
テスト仕様の生成: テストするテーブル、サンプルデータ、アクセスパターンをリストした dynamodb_data_model.json を作成します
スキーマのデプロイ: テーブル、インデックスを作成し、サンプルデータをローカルに挿入します
テストの実行: アクセスパターンで定義されたすべての読み取りおよび書き込み操作を実行します
結果の検証: 各アクセスパターンが正しく効率的に動作することを確認します
反復的な改善: 検証が失敗した場合 (例: パーティションキーの不一致によりクエリが不完全な結果を返す)、ツールは問題を記録し、影響を受けるスキーマを再生成し、すべてのパターンが合格するまでテストを再実行します

検証出力:

dynamodb_model_validation.json: パターンレスポンスを含む詳細な検証結果
validation_result.md: 各アクセスパターンの合格/不合格ステータスを含む検証プロセスの概要
誤ったキー構造、欠落しているインデックス、非効率的なクエリパターンなどの問題を特定します

ソースデータベース分析

source_db_analyzer ツールは、既存のデータベースからスキーマとアクセスパターンを抽出し、DynamoDB モデルの設計を支援します。これは、リレーショナルデータベースから移行する場合に役立ちます。

このツールは、MySQL 向けに 2 つの接続方法をサポートしています。

RDS Data API ベースのアクセス: クラスター ARN を使用したサーバーレス接続
接続ベースのアクセス: ホスト名/ポートを使用した従来の接続

サポートされているデータベース:

MySQL / Aurora MySQL
PostgreSQL
SQL Server
Oracle

実行モード:

セルフサービスモード: SQL クエリを生成し、自分で実行し、結果を提供します (MySQL、PostgreSQL、SQL Server、Oracle)
マネージドモード: AWS RDS Data API 経由の直接接続 (MySQL のみ)

このツールは、本番環境以外のデータベースインスタンスに対して実行することをお勧めします。

セルフサービスモード (MySQL、PostgreSQL、SQL Server、Oracle)

セルフサービスモードでは、AWS 接続なしで任意のデータベースを分析できます。

クエリの生成: ツールが (選択したデータベースに基づいて) SQL クエリをファイルに書き込みます
クエリの実行: データベースに対してクエリを実行します
結果の提供: ツールが結果を解析し、分析を生成します

マネージドモード (MySQL のみ)

マネージドモードでは、ツールを AWS RDS Data API に接続して、既存の MySQL/Aurora データベースを分析し、DynamoDB モデリング用のスキーマとアクセスパターンを抽出できます。

MySQL 統合の前提条件 (マネージドモード)

RDS Data API ベースのアクセスの場合:

RDS Data API が有効になっている MySQL クラスター
AWS Secrets Manager に保存されたデータベース認証情報
RDS Data API と Secrets Manager にアクセスする権限を持つ AWS 認証情報

接続ベースのアクセスの場合:

環境からアクセス可能な MySQL サーバー
AWS Secrets Manager に保存されたデータベース認証情報
Secrets Manager シークレットには、データベースのホスト名と一致する host フィールドが含まれている必要があります (username と password に加えて)。これにより、認証情報が意図されたデータベースホストでのみ使用されることが保証されます。RDS 管理シークレットには、このフィールドが自動的に含まれます。シークレットを手動で作成した場合は、標準構造に従っていることを確認してください。
```
aws secretsmanager create-secret \
    --name "my-db-secret" \
    --secret-string '{
        "engine": "mysql",
        "host": "my-db.cluster-xxx.us-east-1.rds.amazonaws.com",
        "username": "<username>",
        "password": "<password>",
        "dbname": "<database name>",
        "port": 3306
    }'
```
Secrets Manager にアクセスする権限を持つ AWS 認証情報

両方の接続方法に共通: 4. アクセスパターン分析のためにパフォーマンススキーマを有効にします (オプションですが推奨):

DB パラメータグループで performance_schema パラメータを 1 に設定します
変更後に DB インスタンスを再起動します
次のコマンドで確認します: SHOW GLOBAL VARIABLES LIKE '%performance_schema'
チューニングを検討します:
- performance_schema_digests_size - events_statements_summary_by_digest の最大行数
- performance_schema_max_digest_length - ステートメントダイジェストあたりの最大バイト長 (デフォルト: 1024)
パフォーマンススキーマがない場合、分析は情報スキーマのみに基づきます

MySQL 環境変数

MySQL 統合を有効にするには、次の環境変数を追加します。

RDS Data API ベースのアクセスの場合:

MYSQL_CLUSTER_ARN: MySQL クラスター ARN
MYSQL_SECRET_ARN: データベース認証情報を含むシークレットの ARN
MYSQL_DATABASE: 分析するデータベース名
AWS_REGION: クラスターの AWS リージョン

接続ベースのアクセスの場合:

MYSQL_HOSTNAME: MySQL サーバーのホスト名またはエンドポイント
MYSQL_PORT: MySQL サーバーポート (オプション、デフォルト: 3306)
MYSQL_SECRET_ARN: データベース認証情報を含むシークレットの ARN
MYSQL_DATABASE: 分析するデータベース名
AWS_REGION: Secrets Manager が配置されている AWS リージョン

共通オプション:

MYSQL_MAX_QUERY_RESULTS: 分析出力ファイルの最大行数 (オプション、デフォルト: 500)

注意: 明示的なツールパラメータは環境変数よりも優先されます。接続方法 (クラスター ARN またはホスト名) は 1 つだけ指定する必要があります。

MySQL を使用した MCP 設定

RDS Data API ベースのアクセスの場合:

{
  "mcpServers": {
    "awslabs-dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-west-2",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "MYSQL_CLUSTER_ARN": "arn:aws:rds:$REGION:$ACCOUNT_ID:cluster:$CLUSTER_NAME",
        "MYSQL_SECRET_ARN": "arn:aws:secretsmanager:$REGION:$ACCOUNT_ID:secret:$SECRET_NAME",
        "MYSQL_DATABASE": "<DATABASE_NAME>",
        "MYSQL_MAX_QUERY_RESULTS": "500"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

接続ベースのアクセスの場合:

{
  "mcpServers": {
    "awslabs.dynamodb-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.dynamodb-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "default",
        "AWS_REGION": "us-west-2",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "MYSQL_HOSTNAME": "<MYSQL_HOST>",
        "MYSQL_PORT": "3306",
        "MYSQL_SECRET_ARN": "arn:aws:secretsmanager:$REGION:$ACCOUNT_ID:secret:$SECRET_NAME",
        "MYSQL_DATABASE": "<DATABASE_NAME>",
        "MYSQL_MAX_QUERY_RESULTS": "500"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

ソースデータベース分析の使用

データベースに対して source_db_analyzer を実行します（セルフサービスまたはマネージドモード）
生成されたタイムスタンプ付き分析フォルダ（database_analysis_YYYYMMDD_HHMMSS）を確認します
最初に manifest.md ファイルを読みます。このファイルにはすべての分析ファイルと統計情報が一覧表示されています
すべての分析ファイルを読み、スキーマ構造とアクセスパターンを理解します
分析結果を dynamodb_data_modeling と共に使用して、DynamoDB スキーマを設計します

このツールは以下の内容を含む Markdown ファイルを生成します：

スキーマ構造（テーブル、カラム、インデックス、外部キー）
パフォーマンススキーマからのアクセスパターン（クエリパターン、RPS、頻度）
経時的な変更を追跡するためのタイムスタンプ付き分析

スキーマ変換とコード生成

DynamoDB データモデルを設計した後、それを構造化スキーマに変換し、参照用の Python コードを生成できます。LLM を通じて MCP ツールを使用する場合、このワークフロー全体が自動的に行われます。LLM が単一の会話の中でスキーマ変換、検証、コード生成をガイドするため、手動でツールを呼び出す必要はありません。

スタンドアロンで使用する場合は、CLI からこれらのツールを直接呼び出すか、schema.json ファイルを手動で編集し、必要に応じてコードを再生成することもできます。

注意: データモデルの検証（dynamodb_data_model_validation）はコード生成においてオプションです。ただし、生成されたコードを DynamoDB Local に対して usage_examples.py でテストする予定がある場合は、最初に検証を実行することをお勧めします。検証により、DynamoDB Local にテーブルとテストデータが自動的にセットアップされるためです。

データモデルからスキーマへの変換

dynamodb_data_model_schema_converter ツールは、人間が読めるデータモデル（dynamodb_data_model.md）を、DynamoDB テーブル、インデックス、エンティティ、アクセスパターンを表す構造化 JSON スキーマに変換します。この機械可読形式によりコード生成が可能になり、ドキュメント作成やインフラストラクチャプロビジョニングにも拡張できます。

このツールは生成されたスキーマを自動的に検証し、検証に失敗した場合は詳細なエラーメッセージと修正案を提供します。出力は分離のためにタイムスタンプ付きフォルダに保存されます。

スキーマ構造:

生成される schema.json は以下の内容を含む構造化表現です：

テーブル: パーティションキー/ソートキーを持つ1つ以上の DynamoDB テーブル定義
GSI 定義: グローバルセカンダリインデックスの設定（オプション）
エンティティ: 型付きフィールドを持つドメインモデル（User、Order、Product など）
フィールドタイプ: string、integer、decimal、boolean、array、object、uuid
アクセスパターン: パラメータ定義とキーテンプレートを持つ Query/Scan/GetItem 操作
キーテンプレート: パーティションキーとソートキーを生成するためのパターン（例: USER#{user_id}）

この構造化形式はコード生成ツールの入力として機能します。

スキーマファイルの検証

dynamodb_data_model_schema_validator ツールは、コード生成のために schema.json ファイルが適切にフォーマットされていることを検証します。

検証チェック:

必須セクション（table_config、entities）の存在
すべての必須フィールドの存在
フィールドタイプの妥当性（string、integer、decimal、boolean、array、object、uuid）
列挙値の正確性（操作タイプ、戻り値の型）
全エンティティ間でのパターン ID の一意性
gsi_list と gsi_mappings 間での GSI 名の一致
テンプレートで参照されるフィールドがエンティティフィールドに存在すること
正しいパラメータ数を持つ有効な範囲条件
有効な操作と戻り値の型を持つアクセスパターン

セキュリティ:

スキーマファイルは現在の作業ディレクトリまたはそのサブディレクトリ内にある必要があります。セキュリティのため、パス横断の試みはブロックされます。

検証出力の例:

成功:

✅ Schema validation passed!

エラーと修正案:

❌ Schema validation failed:
  • entities.User.fields[0].type: Invalid type value 'strng'
    💡 Did you mean 'string'? Valid options: string, integer, decimal, boolean, array, object, uuid

データアクセス層の生成

generate_data_access_layer ツールは、検証済みの schema.json ファイルから型安全な Python コードを生成します。

生成されるコード:

エンティティクラス: フィールド検証と型安全性を備えた Pydantic モデル
リポジトリクラス: 各エンティティに対する CRUD 操作（作成、読み取り、更新、削除）
アクセスパターン: スキーマから完全に実装されたクエリおよびスキャン操作
ベースリポジトリ: すべてのリポジトリで共有される機能
使用例: 生成されたクラスの使用方法を示すサンプルコード（オプション）
設定: コード品質とフォーマットのための ruff.toml

コード生成の前提条件:

生成された Python コードには以下のランタイム依存関係が必要です：

pydantic>=2.0 - エンティティの検証と型安全性のため
boto3>=1.38 - DynamoDB 操作のため

プロジェクトにインストールします：

uv add pydantic boto3
# or
pip install pydantic boto3

オプションの開発依存関係:

生成されたコードのリントとフォーマットのために：

ruff==0.15.8 - Python リンター兼フォーマッター（推奨）

生成されるファイル構造:

generated_dal/
├── entities.py              # Pydantic entity models
├── repositories.py          # Repository classes with CRUD operations
├── base_repository.py       # Base repository functionality
├── transaction_service.py   # Cross-table transaction methods (if schema includes cross_table_access_patterns)
├── access_pattern_mapping.json  # Pattern ID to method mapping
├── usage_examples.py        # Sample usage code (if enabled)
└── ruff.toml               # Linting configuration

生成されたコードの使用:

生成されたコードは、型安全なエンティティクラスと、すべてのアクセスパターンに対するリポジトリメソッドを提供します：

from generated_dal.repositories import UserRepository
from generated_dal.entities import User

# Initialize repository
repo = UserRepository(table_name="MyTable")

# Create a new user
user = User(user_id="123", username="username", name="John Doe")
repo.create(user)

# Query by access pattern
users = repo.get_user_by_username(username="username")

# Update user
user.name = "Jane Doe"
repo.update(user)

ruff を使用した生成コードのリントとフォーマット：

ruff check generated_dal/        # Check for issues
ruff check --fix generated_dal/  # Auto-fix issues
ruff format generated_dal/       # Format code