Loading ToolBench
Open-source MCP (Mission Control Panel) server for AWS - A powerful, region-independent backend service for AWS operations
This server presents as an Express HTTP service, not a proper MCP server. The codebase defines only 1 tool (validate-credentials) with extremely minimal schema definition and lacks core MCP patterns. The tool has a description but the input schema is skeletal, missing type specifications and parameter descriptions. No output schema is documented. Error handling is present but generic. The server does not implement MCP protocol semantics, it is a plain REST API that happens to have AWS functionality. For an MCP evaluation, this is fundamentally non-compliant.
Validates AWS credentials by calling GetCallerIdentity and returns account information including Account, Arn, and UserId
Not an MCP server, this is a standard Express.js HTTP REST API with no MCP protocol implementation. No MCP tool registration, no stateless request/response envelopes, no _meta protocol fields, no tool listing endpoint, no resource handling, no prompt system.
Input schema is present but extremely underdeveloped. The 'region' parameter has a type and description in the swagger-like definition, but there is no formal JSON Schema with strict type validation, enum constraints, or min/max bounds. The route handler uses destructuring with a default but does not validate the input against the declared schema.
No output schema documented anywhere. The tool returns {Account, Arn, UserId} from AWS STS GetCallerIdentity, but there is no schema definition, field types, or guidance on what structure the LLM should expect. This violates the pattern:tool-description and mxe:response-shaper requirements.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 31 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool name 'validate-credentials' does not follow verb_noun convention (should be 'validate_credentials' with underscore). More critically, the naming is generic, 'validate' does not specify WHAT is being validated. A clearer name would be 'get_aws_account_identity' or 'validate_aws_credentials_and_get_identity', paired with documentation of what is returned.
Tool description is only 135 characters and does not follow LLM-friendly discovery patterns. It lacks explicit guidance on WHEN to use this tool vs. other AWS operations, WHAT the output enables, and any prerequisites. Compare to baseline: A+ tools average 194 chars and are prompt-engineered to answer: what, when, why.
No parameter descriptions in the input schema. The 'region' parameter has a description in code ('AWS region to validate credentials against') but this is NOT visible in any structured schema artifact (no OpenAPI, no JSON Schema file, no MCP tool registration). An LLM parsing the tool definition would see only the parameter name.
Error handling is generic. The service throws AppError but does not classify errors as retryable/user-fixable/fatal. An LLM receiving 'Invalid AWS credentials' has no guidance on what to do next, should it retry? Ask the user? Both are reasonable but unstated. No recovery guidance follows pattern:recovery-guide.
AWS credentials are loaded from environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN). While this avoids putting secrets in tool parameters (correct), there is no audit trail, rate limiting per tool, or permission gating. No scope declarations (e.g. 'read:iam_identity'). No logging of who called the tool and when.
Single tool server. No composition, no chaining, no pagination. Only one operation available means the server provides minimal value in an agent workflow. Real AWS agents need get_s3_buckets, list_iam_users, create_security_group, etc. This is a stub implementation.