de en es ja ko ru zh

DynamoDB Read-Only MCP

Name: DynamoDB Read-Only MCP
Author: jjikky

by jjikky

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

DynamoDB 읽기 전용 MCP

npm 버전 대장간 배지

모델 컨텍스트 프로토콜(MCP)을 사용하여 AWS DynamoDB 데이터베이스를 쿼리하는 서버입니다. 이 서버를 통해 Claude와 같은 LLM은 자연어 요청을 통해 DynamoDB 데이터를 쿼리할 수 있습니다.

특징

이 MCP 서버는 다음과 같은 기능을 제공합니다.

테이블 관리 도구 :
- list-tables : 모든 DynamoDB 테이블 목록을 봅니다.
- describe-table : 특정 테이블에 대한 자세한 정보를 봅니다.
데이터 쿼리 도구 :
- scan-table : 테이블의 데이터 전체 또는 일부를 스캔합니다.
- query-table : 테이블에서 특정 조건과 일치하는 데이터를 검색합니다.
- paginate-query-table : 특정 조건과 일치하는 여러 페이지의 데이터를 검색합니다.
- get-item : 특정 키로 항목 검색
- count-items : 테이블에 있는 항목의 개수를 계산합니다.
자원 :
- dynamodb-tables-info : 모든 테이블에 대한 메타데이터를 제공하는 리소스
- dynamodb-table-schema : 특정 테이블에 대한 스키마 정보를 제공하는 리소스
프롬프트 :
- dynamodb-query-help : DynamoDB 쿼리 작성을 위한 도움말 프롬프트

Related MCP server: Azure Cosmos DB MCP Server

설치 및 실행

아래의 Run with NPX 방법을 사용하면 설치 없이 실행할 수 있습니다.

Smithery를 통해 설치

Smithery를 통해 Claude Desktop용 DynamoDB 읽기 전용 서버를 자동으로 설치하려면:

지엑스피1

설치

저장소를 복제합니다.

git clone https://github.com/jjikky/dynamo-readonly-mcp.git
cd dynamo-readonly-mcp

필요한 패키지를 설치하세요:
```
npm install
```

.env 파일을 만들고 AWS 자격 증명을 설정하세요.

AWS_ACCESS_KEY_ID=your_access_key
AWS_SECRET_ACCESS_KEY=your_secret_key
AWS_REGION=your_region

빌드하고 실행

npm run build
npm start

Claude Desktop에 연결

이 MCP 서버를 Claude Desktop과 함께 사용하려면 Claude Desktop 구성 파일을 수정해야 합니다.

Claude Desktop 구성 파일을 엽니다.
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json

다음과 같이 서버 구성을 추가합니다.

{
  "mcpServers": {
    "dynamodb-readonly": {
      "command": "node",
      "args": ["/absolute-path/dynamo-readonly-mcp/dist/index.js"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your_access_key",
        "AWS_SECRET_ACCESS_KEY": "your_secret_key",
        "AWS_REGION": "your_region"
      }
    }
  }
}

Claude Desktop을 다시 시작합니다.

NPX로 실행

글로벌 설치 없이 npx 사용하여 이 서버를 실행할 수도 있습니다.

{
  "mcpServers": {
    "dynamodb-readonly": {
      "command": "npx",
      "args": ["-y", "dynamo-readonly-mcp"],
      "env": {
        "AWS_ACCESS_KEY_ID": "your_access_key",
        "AWS_SECRET_ACCESS_KEY": "your_secret_key",
        "AWS_REGION": "your_region"
      }
    }
  }
}

사용 예

클로드에게 다음과 같은 질문을 할 수 있습니다.

"DynamoDB에 어떤 테이블이 있는지 알려주시겠어요?"
"Users 테이블의 구조를 설명하세요"
"groupId가 '0lxp4paxk7'인 'Users' 테이블에서 사용자 수를 찾으세요."

건축학

이 MCP 서버는 다음과 같은 계층 구조로 구성되어 있습니다.

클라이언트 인터페이스(Claude Desktop) - 사용자와 LLM 간의 상호 작용
MCP 프로토콜 계층 - 표준화된 메시지 교환 방법을 제공합니다.
DynamoDB 서버 - DynamoDB와 상호 작용하는 기능을 구현합니다.
AWS SDK - AWS DynamoDB 서비스와 통신합니다

주요 작동 메커니즘

1. 초기화 및 연결

서버가 시작되면 다음 프로세스가 발생합니다.

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error('DynamoDB read-only MCP server is running...');
}

StdioServerTransport 표준 입출력을 통해 통신 채널을 설정합니다.
server.connect(transport) MCP 프로토콜을 통해 Claude Desktop에 연결합니다.
연결하는 동안 서버는 지원되는 도구, 리소스 및 프롬프트에 대한 정보를 클라이언트로 전송합니다.

2. 도구 요청 처리

사용자가 Claude에게 "DynamoDB 테이블 목록을 보여주세요"와 같은 질문을 하는 경우:

클로드는 이 요청을 분석하고 list-tables 도구를 호출합니다.
이 요청은 MCP 프로토콜을 통해 서버로 전송됩니다.
서버는 해당 도구 핸들러를 실행합니다.

server.tool('list-tables', 'Gets a list of all DynamoDB tables', {}, async () => {
  try {
    const tables = await listTables();
    return {
      content: [{ type: 'text', text: JSON.stringify(tables, null, 2) }],
    };
  } catch (error) {
    return { isError: true, content: [{ type: 'text', text: `Error: ${error.message}` }] };
  }
});

결과는 MCP 프로토콜을 통해 클로드에게 반환됩니다.
클로드는 이 결과를 자연어로 처리하여 사용자에게 표시합니다.

3. 특정 매개변수 처리

사용자가 "사용자 테이블의 구조를 알려주세요"를 요청하는 경우:

Claude는 이 요청에 describe-table 도구를 사용해야 한다고 결정합니다.
Claude는 매개변수를 { tableName: "Users" } 로 구성합니다.
이 정보는 MCP 서버로 전송됩니다.

server.tool(
  'describe-table',
  'Gets detailed information about a DynamoDB table',
  {
    tableName: z.string().describe('Name of the table to get detailed information for'),
  },
  async ({ tableName }) => {
    // Query table information using the tableName parameter
    const tableInfo = await describeTable(tableName);
    // Return results
  }
);

여기서 z.string() Zod 라이브러리를 사용하여 매개변수의 유효성을 검사합니다.

4. 리소스 처리

리소스는 읽기 전용 데이터를 제공하는 또 다른 MCP 기능입니다.

server.resource('dynamodb-tables-info', 'DynamoDB table information', async () => {
  // Create and return resource data
  const tables = await listTables();
  const tablesInfo = await Promise.all(/* Query table information */);

  return {
    contents: [
      {
        uri: 'dynamodb://tables-info',
        text: JSON.stringify(tablesInfo, null, 2),
        mimeType: 'application/json',
      },
    ],
  };
});

클로드는 리소스에 접근하여 이를 컨텍스트 정보로 사용합니다.

5. 신속한 처리

MCP 서버는 특정 작업에 대한 프롬프트 템플릿을 제공할 수 있습니다.

server.prompt(
  'dynamodb-query-help',
  'A prompt that helps write DynamoDB queries',
  {
    tableName: z.string().describe('Table name to query'),
    queryType: z.enum(['basic', 'advanced']).default('basic'),
  },
  async ({ tableName, queryType }) => {
    // Generate prompt content
    return {
      messages: [
        {
          role: 'user',
          content: { type: 'text', text: helpContent },
        },
      ],
    };
  }
);

이 프롬프트는 사용자가 "Users 테이블에 대한 쿼리를 작성하는 방법을 보여주세요"라고 요청할 때 사용됩니다.

데이터 흐름 요약

사용자는 자연어로 Claude에게 요청을 합니다.
Claude는 요청을 분석하고 적절한 MCP 도구/리소스/프롬프트를 선택합니다.
MCP 클라이언트는 표준화된 형식으로 서버에 요청을 보냅니다.
서버는 요청을 처리하고 AWS DynamoDB API를 호출합니다.
DynamoDB가 결과를 반환합니다.
서버는 결과를 MCP 형식으로 변환하여 클라이언트로 전송합니다.
Claude는 결과를 자연어로 처리하여 사용자에게 제공합니다.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

Available Tools

7 tools

count-itemsB

Count items in a DynamoDB table

ParametersJSON Schema

Name	Required	Description
`expressionAttributeValues`	No	Filter expression attribute values (optional)
`filterExpression`	No	Filter expression (optional)
`tableName`	Yes	Table name

TDQS

B3.1/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 for behavioral disclosure. It states what the tool does but doesn't mention performance characteristics (e.g., whether it's optimized for counting vs. full scans), error handling, or any constraints like rate limits or permissions required for DynamoDB operations.

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, clear sentence with zero wasted words. It's appropriately sized and front-loaded with the essential information, making it highly efficient.

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

Completeness3/5

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

For a tool with 3 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It states the core purpose but lacks context about when to use it versus siblings, behavioral details, or output format, leaving gaps in completeness.

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 three parameters thoroughly. The description adds no additional meaning about parameters beyond implying filtering is possible, which is already covered in the schema. 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.

Purpose4/5

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

The description clearly states the action ('Count') and resource ('items in a DynamoDB table'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'scan-table' or 'query-table' which might also return counts, so it misses the top 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. With siblings like 'scan-table' and 'query-table' that might offer similar functionality, there's no indication of when this specific counting tool is preferred or what its limitations are.

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

describe-tableC

Get detailed information about a DynamoDB table

ParametersJSON Schema

Name	Required	Description	Default
`tableName`	Yes	Name of the table to get details for

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 action ('Get detailed information') but doesn't reveal critical traits like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what 'detailed information' includes (e.g., schema, throughput, status). This leaves significant gaps for safe and effective tool invocation.

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's appropriately sized for a simple tool and front-loaded with the core action, making it easy 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 complexity of DynamoDB operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails (e.g., table properties, metrics), potential side effects, or error handling. For a tool interacting with a database system, more context is needed to ensure reliable use, especially with multiple sibling tools available.

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, with the single parameter 'tableName' clearly documented as 'Name of the table to get details for'. The description doesn't add any semantic context beyond this, such as format constraints or examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though no extra value is provided.

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 ('Get') and resource ('detailed information about a DynamoDB table'), making the purpose understandable. However, it doesn't differentiate from siblings like 'list-tables' (which lists table names) or 'get-item' (which retrieves specific items), leaving some ambiguity about what 'detailed information' specifically entails compared to other table-related 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 on when to use this tool versus alternatives. It doesn't mention scenarios like needing metadata vs. data retrieval, or how it differs from siblings such as 'list-tables' for table enumeration or 'get-item' for item-level details. Without such context, an agent might struggle to choose appropriately among the six sibling tools.

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

get-itemC

Get an item from a DynamoDB table based on a specific key

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Item key (JSON format)
`tableName`	Yes	Table 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 full burden but offers minimal behavioral context. It states the action but doesn't disclose permissions needed, error conditions, rate limits, or what happens if the key doesn't exist. For a database read operation, 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 with zero wasted words. It's appropriately sized and front-loaded with the core purpose, making it easy 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?

For a database read tool with no annotations and no output schema, the description is insufficient. It doesn't explain return values, error handling, or operational constraints. Given the complexity of DynamoDB operations and lack of structured metadata, more context is needed for effective use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning about parameter usage, constraints, or examples beyond what's in the schema. Baseline 3 is appropriate when the schema does all the work.

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 ('Get') and resource ('an item from a DynamoDB table') with the specific mechanism ('based on a specific key'). It distinguishes from siblings like 'scan-table' or 'query-table' by emphasizing key-based retrieval, but doesn't explicitly contrast with all alternatives like 'paginate-query-table'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, when-not scenarios, or compare with sibling tools like 'query-table' for more complex retrievals or 'scan-table' for full table scans.

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

list-tablesB

Get a list of all DynamoDB tables

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/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 what the tool does but doesn't cover critical aspects like whether it's read-only, requires authentication, has rate limits, or what the output format looks like (e.g., pagination, error handling). This leaves significant gaps for an agent.

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, clear sentence with no wasted words, making it front-loaded and easy to parse. It efficiently conveys the core action without unnecessary elaboration, earning full marks for conciseness.

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

Completeness2/5

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

Given the complexity of DynamoDB operations and the lack of annotations and output schema, the description is incomplete. It doesn't explain behavioral traits, return values, or usage context, which are essential for an agent to operate this tool effectively in a real-world scenario.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied as it adequately handles the lack of parameters without redundancy.

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 ('Get') and resource ('list of all DynamoDB tables'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'describe-table' or 'scan-table' that also involve table operations, missing explicit 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?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify if this is for metadata listing versus data retrieval (like 'scan-table') or if there are prerequisites such as permissions. The description lacks context for selection among siblings.

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

paginate-query-tableC

Paginate query results

ParametersJSON Schema

Name	Required	Description
`expressionAttributeValues`	Yes	Filter expression attribute values (JSON format)
`keyConditionExpression`	Yes	Key condition expression (e.g: 'PK = :pk')
`projectionExpression`	No	Projection expression (optional)
`tableName`	Yes	Table name

TDQS

C2.7/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 mentions 'paginate' which implies handling large result sets, but doesn't disclose pagination mechanics (e.g., token-based, limit parameters), rate limits, authentication needs, or what constitutes a 'query' in this context. The description doesn't contradict annotations since none exist.

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

Conciseness5/5

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

The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core functionality ('paginate query results') and contains no 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?

For a pagination tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'paginate' means operationally, how results are returned, error conditions, or relationship to the 'query-table' sibling. The minimal description leaves too many contextual 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 good documentation for all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for high schema coverage without compensating value.

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 'Paginate query results' states a general purpose but lacks specificity about what resource is being paginated (DynamoDB table query results) and how it differs from the sibling 'query-table' tool. It uses a clear verb ('paginate') but doesn't distinguish from 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 on when to use this tool versus the 'query-table' sibling or other query/scan alternatives. The description implies pagination functionality but doesn't specify prerequisites, when pagination is needed, or when other tools might be more appropriate.

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

query-tableC

Query items from a DynamoDB table based on conditions

ParametersJSON Schema

Name	Required	Description
`expressionAttributeValues`	Yes	Filter expression attribute values (JSON format)
`filterExpression`	No	Filter expression (optional)
`indexName`	No	Name of the index to use (optional)
`keyConditionExpression`	Yes	Key condition expression (e.g: 'PK = :pk')
`limit`	No	Maximum number of items to return
`projectionExpression`	No	Projection expression (optional)
`tableName`	Yes	Name of the table to query

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 the tool queries items but doesn't mention whether it's read-only, if it has side effects, rate limits, authentication needs, or what the return format looks like. For a database query 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 purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy 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 complexity of a DynamoDB query tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or behavioral constraints, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.

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 7 parameters thoroughly. The description adds no additional parameter semantics beyond implying 'conditions' relate to the filter and key condition expressions. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context.

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 ('Query items') and resource ('from a DynamoDB table') with the purpose ('based on conditions'), making it easy to understand what the tool does. It distinguishes from siblings like 'scan-table' by specifying querying rather than scanning, though it doesn't explicitly differentiate from 'paginate-query-table' which might be a related operation.

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 'paginate-query-table'. It mentions conditions but doesn't specify that this is for key-based queries in DynamoDB, leaving the agent to infer usage from the tool name and parameters alone.

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

scan-tableC

Scan items from a DynamoDB table

ParametersJSON Schema

Name	Required	Description
`expressionAttributeValues`	No	Filter expression attribute values (JSON format)
`filterExpression`	No	Filter expression (e.g: 'age > :minAge')
`limit`	No	Maximum number of items to return (default: 20)
`projectionExpression`	No	Projection expression (e.g: "id")
`tableName`	Yes	Name of the table to scan

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. 'Scan' implies a read operation, but it doesn't specify whether this is paginated, has performance implications for large tables, requires specific permissions, or what the output format looks like. For a DynamoDB operation with potential complexity, 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 directly states the tool's purpose without any unnecessary words. It's perfectly front-loaded and every word earns its place, making it efficient for an agent to parse.

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 DynamoDB scanning tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'scanning' means in DynamoDB context (sequential reads vs. query efficiency), doesn't mention performance considerations for large tables, and provides no information about return format or pagination behavior.

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 all parameters are documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it doesn't explain relationships between parameters like how 'filterExpression' works with 'expressionAttributeValues' or typical scanning patterns. 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 action ('scan') and resource ('items from a DynamoDB table'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'query-table' or 'paginate-query-table' which might also retrieve data from DynamoDB tables, missing an opportunity for sibling 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 'query-table' or 'get-item'. It doesn't mention typical use cases for scanning (e.g., full table reads vs. indexed queries) or any prerequisites, leaving the agent to infer usage from context 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.

7 tool updatesv1.0.0Apr 29, 2025
- First observedcount-items
- First observeddescribe-table
- First observedget-item
- First observedlist-tables
- First observedpaginate-query-table
- First observedquery-table
- First observedscan-table

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 10:51 across 7 tools

Disambiguation5/5

Every tool has a clearly distinct purpose with no ambiguity: count-items focuses on counting, describe-table on metadata, get-item on single retrieval, list-tables on table enumeration, paginate-query-table on pagination, query-table on conditional queries, and scan-table on full scans. The descriptions clearly differentiate each tool's function, making misselection unlikely.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with hyphens (e.g., count-items, describe-table, get-item). There are no deviations in style or convention, making the naming predictable and easy to understand across the entire set.

Tool Count5/5

With 7 tools, the count is well-scoped for a read-only DynamoDB server, covering essential operations like listing, describing, retrieving, querying, scanning, and counting. Each tool earns its place without redundancy, fitting within the typical 3-15 range for focused server purposes.

Completeness4/5

The tool set provides comprehensive read-only coverage for DynamoDB, including table listing, metadata retrieval, item access, queries, scans, and pagination. A minor gap exists in not supporting batch operations like batch-get-item, but agents can work around this with existing tools, and the core read workflows are well-covered.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
AI2SQLOAuth
io.ai2sql
Text-to-SQL MCP server: read-only queries on PostgreSQL, MySQL and SQL Server with your real schema
Databases Developer Tools
1
RampOAuth
com.ramp.ramp-mcp-remote
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Finance Databases Search
2
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

Related MCP Servers

MCP-Python
Databases Developer Tools Search
rhabraken
F
license
Not graded
quality
D
maintenance
A server that enables interaction with PostgreSQL, MySQL, MariaDB, or SQLite databases through Claude Desktop using natural language queries.
Updated 2 years ago (2025-02-12 06:09 UTC)
1
-
Azure Cosmos DB MCP Server
Databases RAG Systems
robinong79
A
license
B
quality
D
maintenance
A server that enables LLMs like Claude to interact with Azure Cosmos DB databases through natural language queries, acting as a translator between AI assistants and database systems.
Updated 2 years ago (2025-03-24 06:37 UTC)
4
3
MIT
PlayFab MCP Server
Databases RAG Systems Developer Tools
akiojin
A
license
C
quality
A
maintenance
A server that enables LLMs (like Claude and VSCode Copilot) to interact with Azure Cosmos DB data through natural language queries, acting as a translator between AI assistants and your database.
Updated 13 hours ago (2026-10-13 23:19 UTC)
3
15 npm
3
MIT
MCP Database Server
anit05
A
license
Not graded
quality
D
maintenance
This server provides database access capabilities to Claude, supporting SQLite, SQL Server, PostgreSQL, and MySQL databases.
Updated a year ago (2025-07-15 04:32 UTC)
693 npm
MIT

DynamoDB 읽기 전용 MCP

특징

설치 및 실행

Smithery를 통해 설치

설치

빌드하고 실행

Claude Desktop에 연결

NPX로 실행

사용 예

건축학

주요 작동 메커니즘

1. 초기화 및 연결

2. 도구 요청 처리

3. 특정 매개변수 처리

4. 리소스 처리

5. 신속한 처리

데이터 흐름 요약

특허

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches