What can you do with this server?

The DynamoDB MCP Server provides a Model Context Protocol interface for managing Amazon DynamoDB resources with comprehensive capabilities: * Table Management: Create tables with custom configurations, list existing tables, and retrieve detailed table information * Index Management: Create and manage Global Secondary Indexes (GSI) and Local Secondary Indexes (LSI) * Capacity Management: Update provisioned read/write capacity units for tables and GSIs * Data Operations: Insert, retrieve, update, query (with key conditions), and scan (with optional filters) items in DynamoDB tables * Configuration: Supports AWS credentials and Docker setup for deployment

Which integrations are available for this server?

Allows managing Amazon DynamoDB resources, including table management, capacity management, and data operations such as creating tables, managing indexes, updating capacity, and performing CRUD operations on data

How do I use DynamoDB MCP Server?

1. Click on "Install 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., "@DynamoDB MCP Server create a new Users table with userId as the partition key" 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.

en es ja ko zh

DynamoDB MCP Server

by imankamyabi

Overview Schema Related Servers Score Discussions

JavaScript

Remote

DynamoDB MCP Server

A Model Context Protocol server for managing Amazon DynamoDB resources. This server provides tools for table management, capacity management, and data operations.

Author

Iman Kamyabi (ikmyb@icloud.com)

Related MCP server: AWS Athena MCP Server

Features

Table Management

Create new DynamoDB tables with customizable configurations
List existing tables
Get detailed table information
Configure table settings

Index Management

Create and manage Global Secondary Indexes (GSI)
Update GSI capacity
Create Local Secondary Indexes (LSI)

Capacity Management

Update provisioned read/write capacity units
Manage table throughput settings

Data Operations

Insert or replace items in tables
Retrieve items by primary key
Update specific item attributes
Query tables with conditions
Scan tables with filters

Note: Delete operations are not supported to prevent accidental data loss.

Setup

Install dependencies:

npm install

Configure AWS credentials as environment variables:

export AWS_ACCESS_KEY_ID="your_access_key"
export AWS_SECRET_ACCESS_KEY="your_secret_key"
export AWS_REGION="your_region"

Build the server:

npm run build

Start the server:

npm start

Tools

create_table

Creates a new DynamoDB table with specified configuration.

Parameters:

tableName: Name of the table to create
partitionKey: Name of the partition key
partitionKeyType: Type of partition key (S=String, N=Number, B=Binary)
sortKey: (Optional) Name of the sort key
sortKeyType: (Optional) Type of sort key
readCapacity: Provisioned read capacity units
writeCapacity: Provisioned write capacity units

Example:

{
  "tableName": "Users",
  "partitionKey": "userId",
  "partitionKeyType": "S",
  "readCapacity": 5,
  "writeCapacity": 5
}

list_tables

Lists all DynamoDB tables in the account.

Parameters:

limit: (Optional) Maximum number of tables to return
exclusiveStartTableName: (Optional) Name of the table to start from for pagination

Example:

{
  "limit": 10
}

describe_table

Gets detailed information about a DynamoDB table.

Parameters:

tableName: Name of the table to describe

Example:

{
  "tableName": "Users"
}

create_gsi

Creates a global secondary index on a table.

Parameters:

tableName: Name of the table
indexName: Name of the new index
partitionKey: Partition key for the index
partitionKeyType: Type of partition key
sortKey: (Optional) Sort key for the index
sortKeyType: (Optional) Type of sort key
projectionType: Type of projection (ALL, KEYS_ONLY, INCLUDE)
nonKeyAttributes: (Optional) Non-key attributes to project
readCapacity: Provisioned read capacity units
writeCapacity: Provisioned write capacity units

Example:

{
  "tableName": "Users",
  "indexName": "EmailIndex",
  "partitionKey": "email",
  "partitionKeyType": "S",
  "projectionType": "ALL",
  "readCapacity": 5,
  "writeCapacity": 5
}

update_gsi

Updates the provisioned capacity of a global secondary index.

Parameters:

tableName: Name of the table
indexName: Name of the index to update
readCapacity: New read capacity units
writeCapacity: New write capacity units

Example:

{
  "tableName": "Users",
  "indexName": "EmailIndex",
  "readCapacity": 10,
  "writeCapacity": 10
}

create_lsi

Creates a local secondary index on a table (must be done during table creation).

Parameters:

tableName: Name of the table
indexName: Name of the new index
partitionKey: Partition key for the table
partitionKeyType: Type of partition key
sortKey: Sort key for the index
sortKeyType: Type of sort key
projectionType: Type of projection (ALL, KEYS_ONLY, INCLUDE)
nonKeyAttributes: (Optional) Non-key attributes to project
readCapacity: (Optional) Provisioned read capacity units
writeCapacity: (Optional) Provisioned write capacity units

Example:

{
  "tableName": "Users",
  "indexName": "CreatedAtIndex",
  "partitionKey": "userId",
  "partitionKeyType": "S",
  "sortKey": "createdAt",
  "sortKeyType": "N",
  "projectionType": "ALL"
}

update_capacity

Updates the provisioned capacity of a table.

Parameters:

tableName: Name of the table
readCapacity: New read capacity units
writeCapacity: New write capacity units

Example:

{
  "tableName": "Users",
  "readCapacity": 10,
  "writeCapacity": 10
}

put_item

Inserts or replaces an item in a table.

Parameters:

tableName: Name of the table
item: Item to put into the table (as JSON object)

Example:

{
  "tableName": "Users",
  "item": {
    "userId": "123",
    "name": "John Doe",
    "email": "john@example.com"
  }
}

get_item

Retrieves an item from a table by its primary key.

Parameters:

tableName: Name of the table
key: Primary key of the item to retrieve

Example:

{
  "tableName": "Users",
  "key": {
    "userId": "123"
  }
}

update_item

Updates specific attributes of an item in a table.

Parameters:

tableName: Name of the table
key: Primary key of the item to update
updateExpression: Update expression
expressionAttributeNames: Attribute name mappings
expressionAttributeValues: Values for the update expression
conditionExpression: (Optional) Condition for update
returnValues: (Optional) What values to return

Example:

{
  "tableName": "Users",
  "key": {
    "userId": "123"
  },
  "updateExpression": "SET #n = :name",
  "expressionAttributeNames": {
    "#n": "name"
  },
  "expressionAttributeValues": {
    ":name": "Jane Doe"
  }
}

query_table

Queries a table using key conditions and optional filters.

Parameters:

tableName: Name of the table
keyConditionExpression: Key condition expression
expressionAttributeValues: Values for the key condition expression
expressionAttributeNames: (Optional) Attribute name mappings
filterExpression: (Optional) Filter expression for results
limit: (Optional) Maximum number of items to return

Example:

{
  "tableName": "Users",
  "keyConditionExpression": "userId = :id",
  "expressionAttributeValues": {
    ":id": "123"
  }
}

scan_table

Scans an entire table with optional filters.

Parameters:

tableName: Name of the table
filterExpression: (Optional) Filter expression
expressionAttributeValues: (Optional) Values for the filter expression
expressionAttributeNames: (Optional) Attribute name mappings
limit: (Optional) Maximum number of items to return

Example:

{
  "tableName": "Users",
  "filterExpression": "age > :minAge",
  "expressionAttributeValues": {
    ":minAge": 21
  }
}

Sample Questions

Here are some example questions you can ask Claude when using this DynamoDB MCP server:

Table Management

"Create a new DynamoDB table called 'Products' with a partition key 'productId' (string) and sort key 'timestamp' (number)"
"List all DynamoDB tables in my account"
"What's the current configuration of the Users table?"
"Add a global secondary index on the email field of the Users table"

Capacity Management

"Update the Users table capacity to 20 read units and 15 write units"
"Scale up the EmailIndex GSI capacity on the Users table"
"What's the current provisioned capacity for the Orders table?"

Data Operations

"Insert a new user with ID '123', name 'John Doe', and email 'john@example.com'"
"Get the user with ID '123'"
"Update the email address for user '123' to 'john.doe@example.com'"
"Find all orders placed by user '123'"
"List all users who are over 21 years old"
"Query the EmailIndex to find the user with email 'john@example.com'"

Configuration

Setting up AWS Credentials

Obtain AWS access key ID, secret access key, and region from the AWS Management Console.
If using temporary credentials (e.g., IAM role), also obtain a session token.
Ensure these credentials have appropriate permissions for DynamoDB operations.

Usage with Claude Desktop

Add this to your claude_desktop_config.json:

Docker (Recommended)

{
  "mcpServers": {
    "dynamodb": {
      "command": "docker",
      "args": [ "run", "-i", "--rm", "-e", "AWS_ACCESS_KEY_ID", "-e", "AWS_SECRET_ACCESS_KEY", "-e", "AWS_REGION", "-e", "AWS_SESSION_TOKEN", "mcp/dynamodb-mcp-server" ],
      "env": {
        "AWS_ACCESS_KEY_ID": "your_access_key",
        "AWS_SECRET_ACCESS_KEY": "your_secret_key",
        "AWS_REGION": "your_region",
        "AWS_SESSION_TOKEN": "your_session_token"  
      }
    }
  }
}

Building

Docker:

docker build -t mcp/dynamodb-mcp-server -f Dockerfile .

Development

To run in development mode with auto-reloading:

npm run dev

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

12 tools

create_gsiC

Creates a global secondary index on a table

ParametersJSON Schema

Name	Required	Description
`indexName`	Yes	Name of the new index
`nonKeyAttributes`	No	Non-key attributes to project (optional)
`partitionKey`	Yes	Partition key for the index
`partitionKeyType`	Yes	Type of partition key
`projectionType`	Yes	Type of projection
`readCapacity`	Yes	Provisioned read capacity units
`sortKey`	No	Sort key for the index (optional)
`sortKeyType`	No	Type of sort key (optional)
`tableName`	Yes	Name of the table
`writeCapacity`	Yes	Provisioned write capacity units

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It states this is a creation operation but doesn't mention whether this requires specific permissions, whether it's a synchronous or asynchronous operation, what happens if the index already exists, or any rate limits or costs associated. For a complex database operation with 10 parameters, this is inadequate behavioral context.

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 - a single sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resource. Every word earns its place, making this an excellent example of efficient communication.

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 complex database operation with 10 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what a global secondary index is, when one would use it, what the operation returns, or how it differs from local secondary indexes. The agent would need to infer too much from the bare description and parameter names alone.

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 description coverage is 100%, with all parameters well-documented in the input schema. The description adds no additional parameter information beyond what's already in the structured schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.

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 ('global secondary index on a table'), making the purpose immediately understandable. However, it doesn't differentiate this from the sibling tool 'create_lsi' (local secondary index), which would be important context for an AI agent choosing between similar tools.

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 no guidance about when to use this tool versus alternatives. With sibling tools like 'create_lsi', 'create_table', and 'update_gsi' available, the agent receives no help in determining which tool is appropriate for different scenarios. There's no mention of prerequisites, constraints, 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_lsiC

Creates a local secondary index on a table (must be done during table creation)

ParametersJSON Schema

Name	Required	Description
`indexName`	Yes	Name of the new index
`nonKeyAttributes`	No	Non-key attributes to project (optional)
`partitionKey`	Yes	Partition key for the table
`partitionKeyType`	Yes	Type of partition key
`projectionType`	Yes	Type of projection
`readCapacity`	No	Provisioned read capacity units (optional, default: 5)
`sortKey`	Yes	Sort key for the index
`sortKeyType`	Yes	Type of sort key
`tableName`	Yes	Name of the table
`writeCapacity`	No	Provisioned write capacity units (optional, default: 5)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation (implying mutation) and mentions a timing constraint, but lacks details on permissions required, whether the operation is reversible, error conditions, or what happens to existing data. For a complex 10-parameter mutation tool, this is inadequate.

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, efficient sentence that states the core purpose and key constraint without unnecessary words. It's appropriately sized and front-loaded with the essential 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 complex database index creation tool with 10 parameters, no annotations, and no output schema, the description is insufficient. It lacks information about what the tool returns, error handling, permissions needed, or how it interacts with sibling tools like 'create_table'. The timing constraint is helpful but doesn't compensate for other gaps.

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%, providing detailed documentation for all 10 parameters. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3. However, it doesn't explain relationships between parameters (e.g., how projectionType relates to nonKeyAttributes).

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 a local secondary index') and the resource ('on a table'), with specific mention of the constraint 'must be done during table creation'. However, it doesn't explicitly differentiate from sibling 'create_gsi' (global secondary index), which is a closely related alternative.

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 critical constraint ('must be done during table creation'), which implies when to use it, but offers no explicit guidance on when to choose this tool over alternatives like 'create_gsi' or 'create_table'. No prerequisites or exclusions are mentioned beyond the timing constraint.

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

create_tableC

Creates a new DynamoDB table with specified configuration

ParametersJSON Schema

Name	Required	Description
`partitionKey`	Yes	Name of the partition key
`partitionKeyType`	Yes	Type of partition key (S=String, N=Number, B=Binary)
`readCapacity`	Yes	Provisioned read capacity units
`sortKey`	No	Name of the sort key (optional)
`sortKeyType`	No	Type of sort key (optional)
`tableName`	Yes	Name of the table to create
`writeCapacity`	Yes	Provisioned write capacity units

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'specified configuration' but fails to explain critical behaviors like whether this is a mutating operation, what permissions are required, if it's idempotent, or what happens on conflicts. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly with zero wasted content.

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 complex table creation tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or behavioral nuances, leaving too much unspecified for proper agent usage despite the comprehensive parameter 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?

The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond implying configuration is needed, which doesn't provide value beyond what the schema offers. This meets the baseline for high schema coverage.

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 ('new DynamoDB table'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'create_gsi' or 'create_lsi' that also create DynamoDB structures, leaving some ambiguity about when to choose this specific tool.

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 no guidance on when to use this tool versus alternatives like 'create_gsi' or 'create_lsi', nor does it mention prerequisites or context for table creation. It simply states what it does without indicating appropriate scenarios or exclusions.

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

describe_tableC

Gets detailed information about a DynamoDB table

ParametersJSON Schema

Name	Required	Description	Default
`tableName`	Yes	Name of the table to describe

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Gets'), implying it's non-destructive, but doesn't mention authentication requirements, rate limits, error conditions, or what 'detailed information' includes (e.g., schema, throughput, status). For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool. Every word earns its place without being overly terse or verbose.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails (e.g., table properties, indexes, status), which is critical for a metadata tool. With no behavioral context and minimal parameter guidance, it fails to provide enough information for effective agent use despite the simple 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%, with the single parameter 'tableName' clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema—it doesn't clarify format constraints, naming conventions, or examples. The baseline score of 3 reflects adequate coverage when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Gets') and resource ('detailed information about a DynamoDB table'), making the purpose understandable. It distinguishes this from siblings like 'list_tables' (which lists table names) and 'create_table' (which creates tables), but doesn't explicitly differentiate from other read operations like 'get_item' or 'query_table' beyond the resource scope.

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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'describe_table' over 'list_tables' for metadata, or how it differs from 'get_item' or 'query_table' for data retrieval. There are no prerequisites, exclusions, or contextual usage hints provided.

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

get_itemC

Retrieves an item from a table by its primary key

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Primary key of the item to retrieve
`tableName`	Yes	Name of the table

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves an item, implying a read-only operation, but doesn't specify whether it returns null for missing keys, requires specific permissions, has rate limits, or details the return format (e.g., JSON object). For a read tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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, efficient sentence that front-loads the core action ('retrieves an item') and includes essential details ('from a table by its primary key'). There is no wasted text, making it highly concise and well-structured for quick understanding.

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 complexity of database operations, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens if the key doesn't exist, the return format, error conditions, or how it differs from sibling tools like 'query_table'. For a tool with 2 parameters and rich sibling context, more detail is needed to fully guide 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?

Schema description coverage is 100%, with clear descriptions for both parameters ('key' as primary key and 'tableName' as table name). The description adds minimal value beyond the schema by mentioning 'by its primary key,' which reinforces the schema's 'key' parameter but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('retrieves') and resource ('item from a table'), specifying it uses the primary key. It distinguishes from siblings like 'put_item' (create) or 'update_item' (modify) by focusing on retrieval, though it doesn't explicitly contrast with 'query_table' or 'scan_table' for alternative lookup methods.

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 no guidance on when to use this tool versus alternatives like 'query_table' or 'scan_table', which also retrieve items but with different methods (e.g., by query conditions or full scans). It lacks context on prerequisites, such as needing an existing table, or exclusions, like not supporting secondary indexes.

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

list_tablesC

Lists all DynamoDB tables in the account

ParametersJSON Schema

Name	Required	Description	Default
`exclusiveStartTableName`	No	Name of the table to start from for pagination (optional)
`limit`	No	Maximum number of tables to return (optional)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose behavioral traits like pagination behavior (implied by parameters but not explained), rate limits, authentication requirements, or what the output format looks like. This leaves significant gaps for an agent to understand how the tool behaves.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.

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 moderate complexity (listing resources with pagination), lack of annotations, and no output schema, the description is incomplete. It fails to cover key aspects like output format, error handling, or integration with sibling tools, leaving the agent with insufficient context for reliable 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, clearly documenting both optional parameters for pagination and limits. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced coverage.

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 ('Lists') and resource ('all DynamoDB tables in the account'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'describe_table' or 'scan_table', which prevents a perfect score.

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 no guidance on when to use this tool versus alternatives like 'describe_table' for detailed table information or 'scan_table' for data retrieval. It lacks context about prerequisites, such as requiring AWS permissions, or when listing tables is appropriate in a workflow.

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

put_itemC

Inserts or replaces an item in a table

ParametersJSON Schema

Name	Required	Description	Default
`item`	Yes	Item to put into the table
`tableName`	Yes	Name of the table

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Inserts or replaces an item', implying a mutation operation, but fails to detail critical aspects like permissions needed, whether the operation is idempotent, error handling, or side effects. This is a significant gap for a mutation tool with zero annotation coverage.

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, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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 mutation tool with no annotations, no output schema, and incomplete behavioral details, the description is inadequate. It does not explain return values, error conditions, or how 'inserts or replaces' differs from other operations, leaving the agent with insufficient context for reliable 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?

Schema description coverage is 100%, with both parameters ('item' and 'tableName') documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format details or constraints. Given the high schema coverage, a baseline score of 3 is appropriate.

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 ('Inserts or replaces') and the resource ('an item in a table'), making the purpose understandable. However, it does not explicitly differentiate this tool from sibling tools like 'update_item' or 'create_table', which might handle similar operations, so it misses the highest score.

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 no guidance on when to use this tool versus alternatives such as 'update_item' or 'create_table'. It lacks context about prerequisites, exclusions, or specific scenarios, leaving the agent to infer usage based on the name alone.

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

query_tableC

Queries a table using key conditions and optional filters

ParametersJSON Schema

Name	Required	Description
`expressionAttributeNames`	No	Attribute name mappings
`expressionAttributeValues`	Yes	Values for the key condition expression
`filterExpression`	No	Filter expression for results
`keyConditionExpression`	Yes	Key condition expression
`limit`	No	Maximum number of items to return
`tableName`	Yes	Name of the table

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose whether this is a read-only operation, what permissions are required, how results are returned (pagination, format), error conditions, or performance characteristics. The mention of 'optional filters' hints at filtering capability but lacks detail.

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, efficient sentence that communicates the core functionality without unnecessary words. It's front-loaded with the main action and resource, making it immediately understandable.

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 database query tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error handling, authentication requirements, or how it differs from similar operations. The context signals indicate significant complexity that isn't addressed.

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 6 parameters thoroughly. The description adds marginal value by mentioning 'key conditions' (mapping to keyConditionExpression) and 'optional filters' (mapping to filterExpression), but doesn't provide additional semantic context beyond what's in the schema descriptions.

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 ('Queries') and resource ('a table'), specifying it uses 'key conditions and optional filters'. This distinguishes it from siblings like 'scan_table' (full table scan) and 'get_item' (single item retrieval), though it doesn't explicitly name these alternatives.

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 no guidance on when to use this tool versus alternatives like 'scan_table' or 'get_item'. It mentions 'key conditions' which implies it's for indexed queries, but doesn't state this explicitly or provide any exclusion criteria or prerequisites.

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

scan_tableC

Scans an entire table with optional filters

ParametersJSON Schema

Name	Required	Description
`expressionAttributeNames`	No	Attribute name mappings
`expressionAttributeValues`	No	Values for the filter expression
`filterExpression`	No	Filter expression
`limit`	No	Maximum number of items to return
`tableName`	Yes	Name of the table

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions scanning with filters but doesn't disclose critical behavioral traits: whether this is a read-only operation, performance implications of scanning entire tables, pagination behavior, error conditions, or authentication requirements. For a table scanning operation with no annotation coverage, this leaves significant gaps in understanding tool behavior.

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 - a single sentence that communicates the core functionality efficiently. Every word earns its place: 'Scans' (action), 'entire table' (resource and scope), 'with optional filters' (key capability). No wasted words or unnecessary elaboration.

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 this is a database scanning operation with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what scanning returns, performance implications, error handling, or how this differs from query operations. For a potentially resource-intensive table operation, more context about behavior and limitations is needed.

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 5 parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'optional filters' which aligns with filterExpression, expressionAttributeNames, and expressionAttributeValues parameters, but doesn't provide additional context about filter syntax, performance tradeoffs, or relationship between parameters. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose3/5

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

The description 'Scans an entire table with optional filters' clearly states the verb ('scans') and resource ('table'), but is somewhat vague about scope ('entire' vs 'filtered') and doesn't distinguish from sibling tools like 'query_table' or 'get_item'. It provides basic purpose but lacks specificity about what scanning entails compared to alternatives.

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 is provided about when to use this tool versus alternatives like 'query_table' or 'get_item'. The description mentions 'optional filters' but doesn't explain when filtering is appropriate or what distinguishes scanning from querying. Without usage context, the agent must infer based on tool names alone.

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

update_capacityC

Updates the provisioned capacity of a table

ParametersJSON Schema

Name	Required	Description
`readCapacity`	Yes	New read capacity units
`tableName`	Yes	Name of the table
`writeCapacity`	Yes	New write capacity units

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Updates' implies a mutation, but doesn't disclose critical traits like required permissions, whether changes are reversible, potential costs or rate limits, or what happens if invalid capacity values are provided. This is a significant gap for a mutation tool with zero annotation coverage.

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, efficient sentence with zero waste, front-loaded with the core action. It's appropriately sized for the tool's complexity, making it easy to parse quickly without unnecessary elaboration.

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 as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., side effects, error handling) and doesn't explain what the tool returns, leaving the agent with insufficient context for reliable 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 description adds no meaning beyond what the input schema provides, as schema description coverage is 100% with clear parameter descriptions. The baseline score of 3 is appropriate because the schema does the heavy lifting, but the description doesn't compensate with additional context like units of capacity or constraints on values.

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 ('Updates') and resource ('provisioned capacity of a table'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_gsi' or 'update_item', which might also involve updates to table-related resources, leaving some ambiguity about scope.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the table must exist), exclusions (e.g., cannot be used with certain table types), or related tools like 'create_table' or 'describe_table' for context, leaving the agent to infer usage from the name alone.

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

update_gsiC

Updates the provisioned capacity of a global secondary index

ParametersJSON Schema

Name	Required	Description
`indexName`	Yes	Name of the index to update
`readCapacity`	Yes	New read capacity units
`tableName`	Yes	Name of the table
`writeCapacity`	Yes	New write capacity units

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation but doesn't mention whether this requires specific permissions, whether it's a destructive change, what happens to existing capacity settings, rate limits, or what the response looks like. For a capacity management tool with zero annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for what it communicates and is perfectly front-loaded with the essential 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 capacity update tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'provisioned capacity' means in practical terms, what units are used, whether changes are immediate or gradual, what validation occurs, or what happens on failure. The context signals show this is a 4-parameter mutation tool that needs more behavioral context.

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 description coverage is 100%, so all parameters are documented in the input schema. The description doesn't add any additional parameter context beyond what's already in the schema properties. It mentions 'provisioned capacity' which aligns with the readCapacity and writeCapacity parameters, but provides no extra semantic value.

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 ('Updates') and the resource ('provisioned capacity of a global secondary index'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'update_capacity' or 'update_item', but the specificity of 'global secondary index' provides some implicit distinction.

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 no guidance on when to use this tool versus alternatives like 'update_capacity' or 'create_gsi'. It doesn't mention prerequisites, dependencies, or scenarios where this operation is appropriate versus other update operations.

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

update_itemC

Updates specific attributes of an item in a table

ParametersJSON Schema

Name	Required	Description
`conditionExpression`	No	Condition for update (optional)
`expressionAttributeNames`	Yes	Attribute name mappings
`expressionAttributeValues`	Yes	Values for the update expression
`key`	Yes	Primary key of the item to update
`returnValues`	No	What values to return
`tableName`	Yes	Name of the table
`updateExpression`	Yes	Update expression (e.g., 'SET #n = :name')

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Updates' which implies mutation, but fails to describe critical behaviors: whether this is idempotent, what happens if the item doesn't exist, what permissions are required, whether changes are reversible, or what the response format looks like. For a mutation tool with zero annotation coverage, this is a significant gap.

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

Conciseness5/5

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

The description is a single, efficient sentence that gets straight to the point without any wasted words. It's appropriately sized for the tool's complexity and front-loads the core functionality.

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 mutation tool with 7 parameters (including complex nested objects), no annotations, and no output schema, the description is inadequate. It doesn't explain the return values, error conditions, or the behavioral implications of the update operation. The agent would need to rely heavily on the schema alone, missing important contextual information about how this tool behaves in practice.

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 description coverage is 100%, so all parameters are documented in the schema itself. The description adds minimal value beyond what's in the schema - it mentions 'specific attributes' which aligns with the updateExpression parameter, but doesn't provide additional context about parameter relationships or usage patterns. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb ('Updates') and resource ('specific attributes of an item in a table'), making the purpose understandable. However, it doesn't explicitly differentiate this from sibling tools like 'put_item' (which might create/replace items) or 'update_capacity' (which modifies table capacity), leaving some ambiguity about when to choose this specific update tool.

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 no guidance on when to use this tool versus alternatives like 'put_item' (for full item replacement) or 'update_capacity' (for table-level changes). It lacks context about prerequisites (e.g., requires existing item), exclusions, or typical scenarios, leaving the agent to infer usage from the tool name alone.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific DynamoDB operations with no overlap. For example, create_table vs. describe_table vs. update_item are all unambiguous in their functions, and even similar-sounding tools like query_table and scan_table are clearly differentiated in their descriptions.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case throughout, such as create_table, describe_table, and update_item. The naming is predictable and readable, making it easy for agents to understand the action and target resource.

Tool Count5/5

With 12 tools, this server is well-scoped for DynamoDB operations, covering core CRUD, indexing, capacity management, and table lifecycle. Each tool earns its place without being overwhelming or insufficient for the domain.

Completeness4/5

The tool set provides strong coverage of DynamoDB's key operations, including table management, item CRUD, indexing, and capacity updates. A minor gap is the lack of tools for deleting tables or indexes, which could limit full lifecycle management, but core workflows are well-supported.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Chrysai
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2
Dynamik Public Data A
io.github.DynamikOrbits
Public tools to understand Dynamik, discover datasets, and connect account-scoped capabilities.
Open Data Research & Data
41
Studex MCP Server
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1
mcp AOAuth
co.axiom
List datasets, schemas, run APL queries, and use prompts for exploration, anomalies, and monitoring.
Databases Monitoring Search
29

Related MCP Servers

SQLite MCP Server
Databases Developer Tools
YUChoe
A
license
Not graded
quality
D
maintenance
Enables comprehensive SQLite database operations including CRUD operations, schema management, and meta commands across multiple database files through the Model Context Protocol.
Updated 7 months ago (2026-02-08 03:50 UTC)
32
2
MIT
AWS Athena MCP Server
Databases Cloud Platforms
ColeMurray
A
license
Not graded
quality
B
maintenance
Enables execution of SQL queries against AWS Athena databases with schema discovery, query status management, and result retrieval through a standardized Model Context Protocol interface.
Updated 3 days ago (2026-08-31 09:06 UTC)
24
MIT
Grist MCP Server
Databases Workplace & Productivity App Automation
gwhthompson
F
license
A
quality
D
maintenance
Enables interaction with Grist documents, workspaces, and records via the Model Context Protocol. It supports comprehensive operations including SQL querying, schema management, and record CRUD functionality.
Updated 7 months ago (2026-01-30 15:16 UTC)
11
122
3
AWS MCP Server
Cloud Platforms Developer Tools
LokiMCPUniverse
F
license
Not graded
quality
D
maintenance
Enables interaction with AWS services (EC2, S3, Lambda, DynamoDB, etc.) through the Model Context Protocol, allowing natural language management of cloud resources.
Updated a year ago (2025-07-29 21:25 UTC)
2

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/imankamyabi/dynamodb-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server