MCP server for querying Amazon DynamoDB tables via SQL-like interface with metadata discovery
This server provides three read-only DynamoDB query tools with basic naming and descriptions, but falls short of production-grade quality. Tool names follow the verb_noun convention (get_tables, get_columns, run_query), which is positive. However, descriptions are thin and lack key guidance. Parameters are documented in the schema but descriptions are minimal. Output schemas are not formally documented, the tools return CSV text rather than structured objects, which forces LLMs to parse unstructured output. Error handling is minimal (throws RuntimeException with message concatenation). No enums, no examples of structured responses, no pagination guidance, and no security annotations. The code is clear and functional, but does not meet the 54-pattern baseline for production agent tooling.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `dynamodb_get_tables` tool to get a list of available tables. The output of the tool will be returned in CSV format, with the first line containing column headers.
Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source. Use the `dynamodb_get_columns` tool to list available columns on a table. Both `catalog` and `schema` are optional parameters. The output of the tool will be returned in CSV format, with the first line containing column headers.
Execute a SQL SELECT statement.
Output schema not documented. Tools return CSV text; LLMs must parse unstructured strings rather than structured objects. No guidance on CSV column order, data types, or how to handle multi-row results.
dynamodb_run_query description is sparse (27 chars: 'Execute a SQL SELECT statement.'). Does not explain when to use vs discovery tools, what clauses are supported, or how results are paginated. Minimal guidance for LLM selection.
No pagination support documented. Tools may return large result sets; no limit, offset, page_size, or next_cursor parameters. LLMs cannot reason about truncation or discover all results.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No error handling guidance. Tools throw RuntimeException with error messages. No recovery paths (e.g., 'If query fails with syntax error, check table names via dynamodb_get_tables'). LLMs receive stack traces instead of actionable error classification.
catalog and schema parameters are optional but no guidance on defaults. If omitted, what do they default to? How does the LLM know whether to pass them?
dynamodb_run_query parameter 'sql' is required but has no format constraints documented (e.g., max length, allowed SQL keywords, dialect specifics). Inline description mentions 'SQL-92' and valid clauses but is not formal.
No tool composition guidance. After calling get_tables(), which fields does the response contain that are needed for get_columns() calls? Response must include table names; not documented.