Loading ToolBench
A Model Context Protocol server providing tools to read and manipulate AWS resources using an LLM
This server has 19 tools covering S3 and DynamoDB operations with explicit tool registration and JSON Schema input schemas. However, it suffers from critical gaps in parameter descriptions, missing output schema documentation, and inadequate error handling guidance. Tool descriptions are present but minimal (10-30 chars for most), falling below the 50-200 char LLM-optimized range. Many parameter descriptions are vague or missing type constraints. No evidence of per-tool error handling, recovery guidance, or confirmation patterns for destructive operations. The server lacks tool annotations (destructiveHint, idempotentHint) despite operating 6 destructive tools. Composite operations like table creation require complex nested arrays (key_schema, attribute_definitions) with no schema detail or LLM guidance on structure. No pagination documented for list operations. Output schemas are not visible in provided code. Per the rubric baseline, ~40% of servers are C-grade (fair with significant gaps); this one is at that boundary.
Get details about DynamoDB table TTL
Delete an item from a DynamoDB table
Get an item from a DynamoDB table
Put an item into a DynamoDB table
Query items in a DynamoDB table
Update an item in a DynamoDB table
Create a new DynamoDB table
Parameter descriptions are minimal or missing for complex types. 'key_schema' and 'attribute_definitions' in dynamodb_table_create are documented only as 'Key schema for table creation' and 'Attribute definitions for table creation' with no format guidance, structure hints, or examples. LLMs cannot infer valid AWS DynamoDB KeySchemaElement or AttributeDefinition structures without explicit documentation.
No output schema documentation visible. Tools return results but the schema of responses is not defined. LLMs cannot plan downstream operations or extract needed fields without knowing response structure.
Tool descriptions are too short (10-30 chars) to guide LLM selection. Examples: 'Create a new S3 bucket' (23 chars), 'List all S3 buckets' (20 chars), 'Delete a DynamoDB table' (24 chars). Current length provides no context on WHEN to use the tool, what it returns, or prerequisites.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Delete a DynamoDB table
Get details about a DynamoDB table
List all DynamoDB tables
Update a DynamoDB table
Update DynamoDB table TTL configuration
Create a new S3 bucket
Delete an S3 bucket
List all S3 buckets
Delete an object from S3
List objects in an S3 bucket
Read an object's content from S3
Upload an object to S3
Destructive tools (s3_bucket_delete, s3_object_delete, dynamodb_table_delete, dynamodb_item_delete) lack confirmation or dry-run patterns. No evidence of tool annotations (destructiveHint=true) to signal to clients that these operations are irreversible. Agents may execute destructive calls without safeguards.
No tool annotations detected. Neither destructiveHint, idempotentHint, nor readOnlyHint are used to classify tools. This prevents MCP clients from understanding safety properties and adjusting agent behavior (e.g. requiring human approval for destructive operations).
List tools (s3_bucket_list, s3_object_list, dynamodb_table_list) have no documented pagination. No limit, offset, or page_size parameters visible.
Object 'item' parameter in dynamodb_item_put, dynamodb_item_update is typed as 'object' with description 'Item data to put / Updated item data', no guidance on DynamoDB attribute format (must include type descriptors like {"id": {"S": "value"}} or use type wrappers). LLMs will likely pass plain JSON and fail at runtime.
No error recovery guidance. Tools return errors but LLMs have no hints on what to do next. Try search_users() with a partial name." A raw error code or stack trace gives the agent nothing to act on.'
Parameter 'file_content' in s3_object_upload requires Base64 encoding but provides no validation or error message if LLM passes plaintext. No guidance on size limits, encoding format, or format validation.
bucket_name and table_name parameters lack validation constraints (min/max length, allowed characters). S3 bucket names have strict rules (3-63 chars, lowercase, no dots in some regions, no leading/trailing hyphens). DynamoDB table names also have rules. No description includes these constraints.