Loading ToolBench
MCP server for operations automation with tools for managing SQS Dead Letter Queues, OpenSearch logs, and DynamoDB orders
This server has significant definition quality gaps across all dimensions. While tool names follow verb_noun conventions (fetch, get, list), descriptions are vague and lack actionable context. Parameter schemas are present but lack detailed constraints, enums, and dependency documentation. No documented output schemas. Error handling is absent from tool definitions. The server exposes AWS credentials implicitly through environment variables, and there is no explicit error recovery guidance. Most tools read from AWS services (SQS, OpenSearch, DynamoDB) but provide generic descriptions that do not guide LLM selection or usage patterns. The composition is reasonable (one responsibility per tool), but the overall definition maturity is well below production grade.
Retrieves messages from a Dead Letter Queue using its URL.
Retrieves messages from a Dead Letter Queue using its name.
Searches for error logs in OpenSearch, optionally filtered by trace ID and log level.
Gets the order table by order id.
Gets all orders from the order table.
Gets the number of messages in an SQS queue.
Lists all available Dead Letter Queues configured in the system.
Missing output schemas for all tools. LLMs cannot determine what fields to expect, preventing downstream chaining and forcing unstructured parsing.
Descriptions are generic and do not explain WHEN to use each tool or HOW it differs from similar tools. 'Retrieves messages from a Dead Letter Queue' does not clarify queue-by-URL vs queue-by-name distinction or when to call which variant.
Parameter 'visibilityTimeout' uses string type instead of integer with range constraints. LLMs may pass invalid values like '999999' or 'invalid'. Should define as integer, min=1, max=43200.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
No error handling guidance in any tool definition. If DLQ fetch fails due to permissions, missing queue, or service unavailability, LLMs have no recovery path. No distinction between retryable vs permanent failures.
fetchErrorLogs accepts optional 'traceId' and 'level' parameters but does not document how they interact. If traceId is provided, is level ignored? Can both be omitted? Undocumented dependencies cause misuse.
getOrders and getOrderTableByOrderId return no pagination info. If the order table has thousands of records, getOrders returns all of them, exhausting context window. Should accept limit/offset and return total count.
listAvailableDlqs has only 23 characters of description ('Lists all available Dead Letter Queues configured in the system.'). While technically compliant, it lacks context for when to call it (discovery tool, call before using fetchDlqMessages).
No documented relationship between listAvailableDlqs output (DLQ names/URLs) and the input parameters of fetchDlqMessages/fetchDlqMessagesByQueueName. If listAvailableDlqs returns 'order-queue-dlq', does fetchDlqMessagesByQueueName accept that exact string?
Parameter 'size' in fetchErrorLogs is string type with default '10'. Should be integer. No documented maximum, LLM could pass 10000 and overwhelm OpenSearch.