MCP server that lets AI agents query and operate 8 databases (MySQL, PostgreSQL, Redshift, MongoDB, Redis, DynamoDB, Elasticsearch, Kafka) with 145+ tools
DB Gateway provides 33 tools across DynamoDB and Elasticsearch with clear naming conventions (verb_noun), documented descriptions, and structured JSON schemas. However, there are critical gaps: many parameter descriptions are generic or missing context about constraints, output schemas are not explicitly documented, error handling guidance is absent, and several tools lack real-world usage constraints (e.g., pagination limits, safe defaults). The server demonstrates competence in tool registration but falls short of production-grade polish. Description lengths average ~80-150 chars (within 10-1024 range), but parameter annotations are inconsistent, some are detailed while others are minimal. Risk levels are declared (READ_ONLY, WRITE, DESTRUCTIVE) but there's no confirmation pattern for destructive ops, and no recovery guidance in error responses.
Get multiple items from one or more DynamoDB tables in a single request
Put or delete multiple items in one or more DynamoDB tables
Create a new DynamoDB table
Delete an item from a DynamoDB table
Delete a DynamoDB table (WARNING: This permanently removes the table and all its data)
Get detailed information about a DynamoDB table
Destructive tools (delete_table, delete_index, delete_item, delete_document) lack confirmation pattern and no recovery guidance. No dry-run support. Risk of accidental permanent data loss.
Query and scan tools (dynamodb_query, dynamodb_scan, elasticsearch_search, elasticsearch_bulk) have no explicit pagination limits or result cap documented. LLM could request unlimited results, exhausting context window.
Output schemas are not documented in tool definitions. Parameter descriptions do not indicate what fields/structure the tools return. LLMs cannot plan downstream tool calls or extract relevant data.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Get an item from a DynamoDB table by its primary key
List all tables in DynamoDB
Create or replace an item in a DynamoDB table
Query items from a DynamoDB table using key conditions
Scan all items in a DynamoDB table (use with caution on large tables)
Perform multiple Put, Update, Delete, or ConditionCheck operations atomically across one or more tables
Update an existing item in a DynamoDB table
Perform aggregations on documents
Perform bulk operations (index, update, delete) in a single request
Count documents matching a query
Create an alias for an index
Create a new index with optional settings and mappings
Delete an alias from an index
Delete a document by ID
Delete an index (WARNING: This permanently removes the index and all its data)
Get the health status of the ElasticSearch/OpenSearch cluster
Get basic information about the ElasticSearch/OpenSearch cluster
Get a document by its ID
Get detailed information about a specific index
Get the settings of an index
Get the mapping definition of an index
Index (create or update) a document
List all index aliases
List all indices in the ElasticSearch/OpenSearch cluster
Refresh an index to make recent changes searchable
Search for documents using Query DSL
Partially update an existing document
Error handling descriptions are absent. Tools do not guide LLM on recovery: retry vs ask user vs fatal. No actionable error messages shown in definitions.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint per 2026-07-28 spec) are not present in tool definitions. Risk labels (READ_ONLY, WRITE, DESTRUCTIVE) are noted in metadata but not in MCP schema.
Query/scan tools accept complex object parameters (key, item, filter_expression) without format guidance or validation rules. LLMs may struggle to construct valid DynamoDB expressions or Elasticsearch queries.
Parameter descriptions for complex inputs (key_schema, attribute_definitions, transact_items, operations) are generic. No examples or format guidance beyond brief parenthetical notes.
No idempotency guarantees documented for write tools. LLMs may not know if retry-on-failure will cause duplicate records (double-put, duplicate index operations).