Loading ToolBench
Node.js/TypeScript MCP server for AWS Single Sign-On (SSO). Enables AI systems (LLMs) with tools to initiate SSO login (device auth flow), list accounts/roles, and securely execute AWS CLI commands using temporary credentials. Streamlines AI interaction with AWS resources.
This AWS SSO MCP server demonstrates solid tool engineering with comprehensive descriptions, well-structured schemas, and actionable error guidance. All 5 tools have detailed, LLM-optimized descriptions (150-300 chars typical) that explain WHAT the tool does, WHEN to use it, and prerequisites. Input schemas are present with type definitions for all parameters. Tool names follow verb_noun convention (aws_sso_login, aws_sso_exec_command). However, the server lacks tool annotations (readOnlyHint/destructiveHint/idempotentHint) that would help agents understand mutation semantics, and output schemas are not formally documented in the source code excerpts provided. Error handling is present in the implementation but recovery guidance in descriptions is minimal. The server correctly accepts structured AWS identifiers (accountId, roleName) rather than relying on opaque IDs alone, enabling natural composition.
Execute shell command on EC2 instance via SSM using AWS SSO credentials. No SSH access or inbound ports required. Uses SSM's RunShellScript document. Prerequisites: - MUST first authenticate using `aws_sso_login` - EC2 instance MUST have SSM Agent installed - Instance needs IAM role with AmazonSSMManagedInstanceCore policy - Your role needs `ssm:SendCommand` and `ssm:GetCommandInvocation` permissions Required: `instanceId`, `accountId`, `roleName`, `command` Optional: `region` Returns: Execution context, command output, errors, troubleshooting guidance
Execute AWS CLI command using temporary credentials from AWS SSO. Workflow: 1. Verifies valid AWS SSO authentication token 2. Obtains temporary credentials for account and role 3. Executes the AWS CLI command 4. Caches credentials for future use (1 hour) Prerequisites: - MUST first authenticate using `aws_sso_login` - AWS CLI MUST be installed on the system - AWS SSO must be configured Required: `accountId`, `roleName`, `command` Optional: `region` Returns: Execution context, command output, errors, exit code
Initiate AWS SSO device authorization flow to obtain temporary credentials. This flow works as follows: 1. Generates a unique user verification code and authentication URL 2. Opens a browser to AWS SSO login page (if `launchBrowser: true`) 3. You enter the verification code and complete AWS SSO login 4. Background polling automatically collects and caches the token 5. The cached token is used by other AWS SSO tools **IMPORTANT FOR AI ASSISTANTS**: When the tool returns authentication instructions: - ALWAYS check if a browser window opened automatically - If browser opened: Guide the user to complete authentication - If no browser opened: Instruct user to manually open the URL and enter code - Always provide both the verification code and URL as backup Prerequisites: - AWS SSO must be configured with a start URL and region - Browser access is required for authentication - You must have an AWS SSO account with appropriate permissions Returns: Authentication status, session details, verification code and URL
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent. This forces LLMs to infer mutation semantics from descriptions alone, increasing hallucination risk for destructive operations like aws_sso_exec_command and aws_sso_ec2_exec_command.
Output schemas are not formally documented. The source code shows tool registration and descriptions but does not expose structured output schema definitions (response field types, cardinality, pagination info). LLMs cannot infer what fields to expect or plan downstream tool chains.
Recovery guidance in error handling is weak. Descriptions mention 'Returns: Execution context, command output, errors, exit code' but do not explain what the LLM should do on common failures (e.g., 'If SSM command times out, retry with increased wait time; if instance not reachable, verify SSM Agent is running').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | A | 81 | <=2025-11-25 | v2 |
| 2026-04-07 | F | 25 | - | v1 |
List all AWS accounts and roles accessible through AWS SSO. Provides essential information needed for `aws_sso_exec_command`: - Fetches all accessible accounts with IDs, names, and emails - Retrieves all available roles for each account - Handles pagination internally - Caches account and role information Prerequisites: - MUST first authenticate using `aws_sso_login` - AWS SSO must be configured with a start URL and region Returns: Account list with IDs, names, roles, and session status
Check current AWS SSO authentication status. Verifies if a valid cached token exists and its expiration time. Does NOT perform authentication - only checks status. If no valid token exists, instructs you to run `aws_sso_login`. Use before calling `aws_sso_ls_accounts` or `aws_sso_exec_command`. Returns: Authentication status, session details, expiration time, next steps
The 'region' parameter in aws_sso_exec_command and aws_sso_ec2_exec_command is marked optional but the description does not explain default behavior or how the LLM should determine when to specify it. This ambiguity invites incorrect calls.
Pagination is not documented for aws_sso_ls_accounts. The description states 'Handles pagination internally' but does not expose page/offset/limit parameters or document result cardinality limits. If an account has thousands of roles, the response could exceed context windows.