The sequence is fixed and worth learning: log in, list accounts to get the account ID and role name, then execute — and check status first, since a stale token turns every later call into a failure. The EC2 tool goes through SSM rather than SSH, so nothing has to be exposed inbound, but the instance needs the agent and an IAM role that allows it.
An AWS SSO front door for an agent: it runs the device authorization flow, caches the token, and then executes AWS CLI commands under temporary credentials for whichever account and role you name.
- aws_sso_login runs the device authorization flow: a verification code, the AWS SSO page opened in a browser if you let it, and the token cached afterwards
- aws_sso_status reports whether that cached token is still valid and when it expires, without authenticating again
- aws_sso_ls_accounts lists every account and role you can reach, paginating and caching internally — this is where the account ID and role name the other tools need come from
- aws_sso_exec_command runs an AWS CLI command under temporary credentials for a chosen account, role and region, caching those credentials for an hour
- aws_sso_ec2_exec_command runs a shell command on an EC2 instance through SSM's RunShellScript document, with no SSH and no inbound ports open
- Every tool is also a kebab-case CLI command, so the same operations work from a terminal without an agent
AWS IAM Identity Center already set up, with the portal URL in AWS_SSO_START_URL and the SSO region in AWS_SSO_REGION or AWS_REGION. You approve the device authorization in a browser once; the token is cached, and per-account, per-role credentials are then cached for an hour. The EC2 path additionally needs the SSM Agent on the instance and an instance IAM role that permits SSM. TRANSPORT_MODE picks stdio or http, with PORT defaulting to 3000 and the endpoint at /mcp. Run it with npx -y @aashari/mcp-server-aws-sso, or keep the environment block in ~/.mcp/configs.json for a system-wide setup.
One command — npx -y @aashari/mcp-server-aws-sso