en es ja ko zh

DynamoDB MCP Server

Name: DynamoDB MCP Server
Author: imankamyabi

by imankamyabi

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

DynamoDB MCP 服务器

用于管理 Amazon DynamoDB 资源的模型上下文协议服务器。此服务器提供用于表管理、容量管理和数据操作的工具。

作者

伊曼·卡米亚比 ( ikmyb@icloud.com )

Related MCP server: AWS Athena MCP Server

特征

表管理

使用可自定义的配置创建新的 DynamoDB 表
列出现有表
获取表的详细信息
配置表设置

指数管理

创建和管理全局二级索引 (GSI)
更新 GSI 容量
创建本地二级索引 (LSI)

容量管理

更新预配置的读/写容量单位
管理表吞吐量设置

数据操作

插入或替换表中的项目
按主键检索项目
更新特定项目属性
带条件的查询表
使用过滤器扫描表格

注意：不支持删除操作，以防止意外数据丢失。

设置

安装依赖项：

npm install

将 AWS 凭证配置为环境变量：

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

构建服务器：

npm run build

启动服务器：

npm start

工具

创建表

使用指定的配置创建一个新的 DynamoDB 表。

参数：

tableName ：要创建的表的名称
partitionKey ：分区键的名称
partitionKeyType ：分区键的类型（S=字符串，N=数字，B=二进制）
sortKey ：（可选）排序键的名称
sortKeyType ：（可选）排序键的类型
readCapacity ：预配置的读取容量单位
writeCapacity ：预配置的写入容量单位

例子：

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

列表表

列出账户中的所有 DynamoDB 表。

参数：

limit ：（可选）返回的最大表数
exclusiveStartTableName ：（可选）分页起始表的名称

例子：

{
  "limit": 10
}

描述表

获取有关 DynamoDB 表的详细信息。

参数：

tableName ：要描述的表的名称

例子：

{
  "tableName": "Users"
}

创建_gsi

在表上创建全局二级索引。

参数：

tableName ：表的名称
indexName : 新索引的名称
partitionKey ：索引的分区键
partitionKeyType ：分区键的类型
sortKey ：（可选）索引的排序键
sortKeyType ：（可选）排序键的类型
projectionType ：投影类型（ALL、KEYS_ONLY、INCLUDE）
nonKeyAttributes ：（可选）项目的非关键属性
readCapacity ：预配置的读取容量单位
writeCapacity ：预配置的写入容量单位

例子：

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

更新_gsi

更新全局二级索引的预配置容量。

参数：

tableName ：表的名称
indexName ：要更新的索引的名称
readCapacity ：新的读取容量单位
writeCapacity ：新的写入容量单位

例子：

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

创建lsi

在表上创建本地二级索引（必须在表创建期间完成）。

参数：

tableName ：表的名称
indexName : 新索引的名称
partitionKey ：表的分区键
partitionKeyType ：分区键的类型
sortKey ：索引的排序键
sortKeyType ：排序键的类型
projectionType ：投影类型（ALL、KEYS_ONLY、INCLUDE）
nonKeyAttributes ：（可选）项目的非关键属性
readCapacity ：（可选）预配置的读取容量单位
writeCapacity ：（可选）预配置的写入容量单位

例子：

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

更新容量

更新表的预配置容量。

参数：

tableName ：表的名称
readCapacity ：新的读取容量单位
writeCapacity ：新的写入容量单位

例子：

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

放置物品

在表中插入或替换项目。

参数：

tableName ：表的名称
item ：要放入表中的项目（作为 JSON 对象）

例子：

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

获取项目

通过主键从表中检索项目。

参数：

tableName ：表的名称
key ：要检索的项目的主键

例子：

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

更新项目

更新表中项目的特定属性。

参数：

tableName ：表的名称
key ：要更新的项目的主键
updateExpression ：更新表达式
expressionAttributeNames ：属性名称映射
expressionAttributeValues ：更新表达式的值
conditionExpression ：（可选）更新条件
returnValues ：（可选）返回什么值

例子：

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

查询表

使用关键条件和可选过滤器查询表。

参数：

tableName ：表的名称
keyConditionExpression ：关键条件表达式
expressionAttributeValues ：关键条件表达式的值
expressionAttributeNames ：（可选）属性名称映射
filterExpression ：（可选）结果的过滤表达式
limit ：（可选）返回的最大项目数

例子：

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

扫描表

使用可选过滤器扫描整个表。

参数：

tableName ：表的名称
filterExpression ：（可选）过滤表达式
expressionAttributeValues ：（可选）过滤表达式的值
expressionAttributeNames ：（可选）属性名称映射
limit ：（可选）返回的最大项目数

例子：

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

示例问题

以下是您在使用此 DynamoDB MCP 服务器时可以向 Claude 询问的一些示例问题：

表管理

“创建一个名为‘Products’的新 DynamoDB 表，其分区键为‘productId’（字符串），排序键为‘timestamp’（数字）”
“列出我的账户中的所有 DynamoDB 表”
“用户表的当前配置是什么？”
“在用户表的电子邮件字段上添加全局二级索引”

容量管理

“将用户表容量更新为 20 个读取单元和 15 个写入单元”
“扩大用户表上的 EmailIndex GSI 容量”
“订单表的当前配置容量是多少？”

数据操作

“插入一个新用户，ID 为‘123’，名称为‘John Doe’，电子邮件为‘ john@example.com ’”
“获取 ID 为‘123’的用户”
“将用户‘123’的电子邮件地址更新为‘ john.doe@example.com ’”
“查找用户‘123’下的所有订单”
“列出所有超过 21 岁的用户”
“查询 EmailIndex 来查找电子邮件为‘ john@example.com ’的用户”

配置

设置AWS凭证

从 AWS 管理控制台获取 AWS 访问密钥 ID、秘密访问密钥和区域。
如果使用临时凭证（例如 IAM 角色），还可以获取会话令牌。
确保这些凭证具有 DynamoDB 操作的适当权限。

与 Claude Desktop 一起使用

将其添加到您的claude_desktop_config.json中：

Docker（推荐）

{
  "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"  
      }
    }
  }
}

建筑

Docker：

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

发展

要在开发模式下运行并自动重新加载：

npm run dev

执照

此 MCP 服务器采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件，但须遵守 MIT 许可证的条款和条件。更多详情，请参阅项目仓库中的 LICENSE 文件。

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv1.0.0Aug 18, 2025
- First observedcreate_gsi
- First observedcreate_lsi
- First observedcreate_table
- First observeddescribe_table
- First observedget_item
- First observedlist_tables
- First observedput_item
- First observedquery_table
- First observedscan_table
- First observedupdate_capacity
- First observedupdate_gsi
- First observedupdate_item

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

B3.4/5.0

Scored 2026-04-18 11:50 across 12 tools

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

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

StructuraOAuth
tools.structura
Design domain models and generate deterministic multi-stack code, driven by your coding agent.
Developer Tools Software Architecture
1
ChrysaiOAuth
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
AgentUI AppsOAuth
ai.agentui
Create AgentUI data apps: define tables, read and write records, and run programs on your data.
1

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 8 months ago (2026-02-08 03:50 UTC)
25 npm
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 8 days ago (2026-10-05 09:05 UTC)
123 PyPI
23
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 8 months ago (2026-01-30 15:16 UTC)
11
204 npm
4
-
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
-

DynamoDB MCP 服务器

作者

特征

表管理

指数管理

容量管理

数据操作

设置

工具

创建表

列表表

描述表

创建_gsi

更新_gsi

创建lsi

更新容量

放置物品

获取项目

更新项目

查询表

扫描表

示例问题

表管理

容量管理

数据操作

配置

设置AWS凭证

与 Claude Desktop 一起使用

Docker（推荐）

建筑

发展

执照

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches