Loading ToolBench
MCP server for running AWS code and managing AWS credentials/profiles
aws-mcp has three tools with basic schema definitions, but critical issues undermine their quality. Tool descriptions vary in usefulness but lack clarity on when to use each tool vs. alternatives. Parameter descriptions are present but often vague. The 'code' parameter description in run-aws-code is replaced entirely with a system prompt (codePrompt), which is inappropriate and wastes tokens for LLM reasoning. Error handling is minimal, tools return plain text responses without structured guidance. No output schemas are documented. Tool composition is reasonable (three separate concerns), but parameter naming and parameter validation guidance are weak.
List all AWS credentials/configs/profiles that are configured/usable on this machine
Run AWS code
Selects AWS profile to use for subsequent interactions. If needed, does SSO authentication
run-aws-code 'code' parameter description is a 1500+ character system prompt instead of a user-facing parameter guide. This wastes tokens in every LLM reasoning cycle and violates the 10 - 1024 character description baseline. LLMs cannot use a system prompt as a parameter constraint.
No output schemas documented for any tool. LLMs do not know what fields to expect from responses, forcing unstructured parsing. For example, run-aws-code returns 'JSON.stringify(result)' (plaintext), list-credentials returns '{profiles: [...], error: ...}', but neither declares the structure to the LLM.
Parameter 'profileName' in run-aws-code is optional, but the tool logic requires either selectedProfile (stateful) or profileName to be set. If neither is provided, the tool rejects the call with 'Please select a profile first'. This hidden dependency is not documented in the parameter description. Undocumented parameter dependencies cause silent misuse.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
No error recovery guidance. When a profile is not selected, the tool returns a plain string. When user code fails to execute, the tool returns JSON.stringify(error) with no hints on what to do next. Error responses should guide the LLM: 'User profile not found. Call list-credentials to see available profiles, then select-profile to activate one.'
run-aws-code is a WRITE tool (executes arbitrary AWS code), but the description does not state this. Agents need to know that calls to this tool are not read-only, not idempotent, and have irreversible consequences. No destructiveHint annotation is present.
Stateful tool behavior: selectedProfile, selectedProfileCredentials, and selectedProfileRegion are mutable module-level variables shared across calls. The server does not isolate per-session or per-user state. If two concurrent agents use this server, they will interfere with each other's profile selections. MCP is stateless by design, state should be passed via parameters or stored server-side with per-client keys.
Parameter descriptions lack format and constraint guidance. 'region' accepts a string, but valid AWS regions are not documented (e.g. 'us-east-1, eu-west-1, ...'). 'profileName' accepts a string, but the LLM does not know valid profile names without calling list-credentials first. Descriptions should state: 'AWS region code (e.g. us-east-1, eu-west-1; see list-credentials for your configured profiles).'
No input validation in the CallToolRequestSchema handler. After Zod parsing, the code trusts profileName and region without checking that profiles[profileName] exists. Invalid profile names silently fail with a 500-level error. Early validation with actionable error messages is missing.