Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@updsts update STS credentials for profile dev using TOTP 123456"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A simple CUI tool and local MCP server for reflecting AWS STS credential information into the credential file
English | 日本語
updsts is a command-line tool that retrieves AWS STS (Security Token Service) credentials from existing AWS credential (.aws/credentials) file information and automatically reflects them in the credential file.
It also has local MCP server functionality that automatically updates temporary credential information in AWS credential files, enabling operation through common Agent tools.
Related MCP server: Aws Claw
Obtain temporary AWS STS credentials using MFA authentication
Automatically update AWS credentials file with new session tokens
Support for TOTP-based MFA devices
List all AWS profiles in credentials file
Preserve existing credential profiles safely
Can be operated from common Agent tools when functioning as a local MCP server.
(Of course, care is taken to ensure that confidential information such as secret keys and session tokens is not sent to the LLM.)
Support for proxy environments
This project uses uv as the package manager.
Using uv allows you to automatically reproduce the runtime environment.
For uv installation, see here:
Install and use in a uv environment.
# Install directly from git repository
uv tool install git+{repository_url}After installation, you can use the updsts command directly as a tool.
updsts --helpBy registering as an MCP server, you can operate updsts from common Agent tools.
{
// Example configuration for registering as MCP server
//
// (Note)
// Registration keys may differ depending on the Agent tool used,
// so please refer to the manual of each Agent tool you use for detailed procedures.
"mcpServers" {
// Configuration for starting updsts as MCP server using uv
"updsts-uv": {
"type": "stdio",
"command": "updsts",
"args": [
"mcp",
"--mcp-server"
],
"env": {},
}
}
}-v, --verbose LEVEL: Set output information detail level (0: normal, 1: verbose, 2: debug)
-c, --credential-file FILE: Path to the AWS credentials file (default: ~/.aws/credentials)
get CommandGet and update STS credentials for the specified AWS profile.
updsts get -n <profile_name> -t <totp_token>-n, --profile: AWS profile name to get STS token (required)
-t, --totp-token: TOTP token generated by MFA device (required)
-sn, --sts-profile-name: STS profile name to generate in AWS credentials file (optional, default: AWS profile name + "_sts")
-d, --duration: Token duration in seconds (optional, default: 3600)
-c, --credential-file: Path to credentials file (optional, default: ~/.aws/credentials)
list CommandDisplay all AWS profiles in the credentials file.
updsts listmcp CommandStart the module as a local MCP server.
You can operate updsts using Agent tools.
updsts mcp --mcp-serverIf the --mcp-server option is not specified, it will output the MCP tool list.
updsts mcpupdsts works with standard AWS CLI credentials file format.
It preserves existing profiles while updating only the specified sections.
Example credentials file:
[default]
# Access Key ID (required)
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
# Secret Access Key (required)
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLE
# IAM user's MFA device ARN (required. User must add this)
mfa_device_arn = arn:aws:iam::123456789012:mfa/user
# TOTP secret name managed by mktotp mcp server (optional. User can add this)
# If this is configured and the `mktotp` mcp server is available, Agent will auto-generate and use TOTP token.
totp_secret_name = my_totp_secret
# The section enclosed by the following tags is automatically created/updated by updsts.
# ${{{ key=<profile name that requested STS> [auto update by updsts]
[default_sts]
aws_access_key_id = ASIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYtempKEY
aws_session_token = IQoJb3JpZ2luX2VjE...
expiration_datetime = 2025-10-05T15:30:00+09:00
# $}}} [auto update by updsts]updsts automatically manages sections between special tags while leaving other profiles intact.
Tags are automatically added during the first execution, so there is no need to add them manually.
By default, AWS credentials are stored in the following location.
※ This is the same file used by the AWS CLI.
~/.aws/credentialsYou can specify a different location with the -c option.
When started as an MCP server, the following tools are available from Agent tools.
updsts_update_sts_credentialGet STS credentials for the specified AWS profile and create/update the sts profile in the credential file.
Parameters:
profile_name (str): AWS profile name to update (required)
totp_token (str): TOTP token from MFA device (required)
sts_profile_name (str | None): STS profile name to create in AWS credentials file (optional)
If None or empty string, <profile_name>_sts will be used (default: None)
cred_file (str | None): Path to credentials file (optional)
If None or empty string, default location (~/.aws/credentials) is used (default: None)
duration (int): STS token duration in seconds (optional, default: 3600)
Returns (dict[str, str] | None): Dictionary containing updated credential details or None if failed
updsts_get_credential_infoGet AWS credential information for the specified profile name in the credential file.
However, for security reasons, aws_secret_access_key and aws_session_token are returned masked.
Parameters:
profile_name (str): AWS profile name to retrieve (required)
cred_file (str | None): Path to credentials file (optional)
If None or empty string, default location (~/.aws/credentials) is used (default: None)
Returns (dict[str, str] | None): Dictionary containing credential details or None if not found
updsts_get_credential_info_listGet AWS credential information for all profiles in the credentials file.
However, for security reasons, aws_secret_access_key and aws_session_token are returned masked.
Parameters:
cred_file (str | None): Path to credentials file (optional)
If None or empty string, default location (~/.aws/credentials) is used (default: None)
Returns (list[dict[str, str]]): List of dictionaries containing credential details or empty list if no profiles found
AWS credentials files contain sensitive information, so protect them with appropriate permission settings (recommended: 600)
This project is licensed under the MIT License.
See the LICENSE file for details.
Get registerd AWS credential information for the specified profile.
This tool retrieves the registerd AWS credentials for the specified profile name from the AWS credentials file.
| Name | Required | Description | Default |
|---|---|---|---|
| cred_file | No | Credential file path. If empty string, the default credential file will be used. | |
| profile_name | Yes | Profile name to get sts secret key. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose the data source (the AWS credentials file) and that results are per-profile, but it does not state that this is a read-only operation returning sensitive secret material, nor what happens when the profile is absent or file unreadable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The second sentence restates the first almost verbatim, adding no new information, and both instances of 'registerd' are misspelled. The core statement is front-loaded but roughly half the text is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values need not be explained since an output schema exists, and both parameters are schema-documented. However, the description omits the routing guidance and existence/permission caveats an agent would need for a credentials-reading tool with two siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both `cred_file` (default-file fallback) and `profile_name` are already documented by the schema. The description only echoes the profile-name concept and adds no format, encoding, or path-syntax detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Get/retrieves) and resource (AWS credential information) scoped to a profile name, so the agent knows exactly what it returns. It does not explicitly distinguish itself from the sibling `updsts_get_credential_info_list`, though 'for the specified profile' implicitly signals single-profile scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus `updsts_get_credential_info_list` or `updsts_update_sts_credential`, and no preconditions (e.g., profile must already exist in the credentials file). The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get registerd AWS credential information list for all profiles.
This tool retrieves the all AWS credentials in the cred_file.
| Name | Required | Description | Default |
|---|---|---|---|
| cred_file | No | Credential file path. If empty string, the default credential file will be used. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' implies a read, but it does not state permissions, whether it touches disk at the given path, or what happens when cred_file is empty beyond what the schema already says. Behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that largely restate each other ('Get ... credential information list' vs 'retrieves the all AWS credentials'), with typos ('registerd', 'the all'). The second sentence adds no information and should have been cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with an output schema, the definition is minimally sufficient: it names the resource and the source file. It leaves out any indication of auth requirements or failure modes, but the output schema covers the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter and schema description coverage is 100%, so the schema already explains cred_file and the empty-string default. The description only restates that credentials come from cred_file, adding nothing new; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieving registered AWS credential info for all profiles. It is distinguishable from the sibling updsts_get_credential_info (singular) by the 'list / all profiles' scope, though it never explicitly contrasts them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus updsts_get_credential_info or updsts_update_sts_credential. An agent must infer that the plural 'list' variant is for enumerating all entries; nothing in the text confirms or excludes that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get and update AWS credentials for the specified profile using TOTP token.
This tool obtains temporary STS credentials using MFA authentication and updates the AWS credentials file with the new session token and keys.
| Name | Required | Description | Default |
|---|---|---|---|
| duration | No | Duration seconds of the sts token (default: 3600). | |
| cred_file | No | Credential file path. If empty string, the default credential file will be used. | |
| totp_token | Yes | TOTP token of ARN device. | |
| profile_name | Yes | Profile name to get sts secret key. | |
| sts_profile_name | No | STS Profile name in the AWS credentials file. If empty string, '<profile_name>_sts' will be used. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that this is a mutating operation, that it writes the session token and keys into the AWS credentials file, and that MFA authentication is required. However, it omits overwrite semantics for an existing profile, error/failure behavior, and whether the credentials file is created if missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action. Slight redundancy: 'Get and update' in the first sentence is restated by 'obtains temporary STS credentials ... and updates the AWS credentials file' in the second.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and all parameters are schema-documented. The description covers the mutation and MFA requirement adequately; only edge-case behavior (existing profile overwrite, credential-file creation) is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters including defaults. The description adds only the MFA/TOTP context, not format, syntax, or interaction details (e.g., the relationship between profile_name and sts_profile_name) beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: obtaining temporary STS credentials via MFA and updating the AWS credentials file. An agent can distinguish it from the sibling read-only tools (get_credential_info / get_credential_info_list) by the mint-and-write behavior, though the siblings are not named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what it does but never states when to use it versus the two sibling tools, nor any preconditions (e.g., that TOTP token must come from an MFA device, or what to do if a valid session already exists). Usage must be inferred entirely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.8.8updsts_get_credential_infoupdsts_get_credential_info_listupdsts_update_sts_credentialScored across 3 tools
The three tools are largely distinct: one updates STS credentials, one gets info for a single profile, and one lists info for all profiles. The get_credential_info vs get_credential_info_list pair could be momentarily confused, but the singular/plural distinction is clear enough.
All names share the updsts_ prefix and follow a verb_noun snake_case pattern (update_sts_credential, get_credential_info, get_credential_info_list). Minor redundancy in the prefix and the trailing _list is a slight deviation, but overall predictable.
Three tools is a focused, well-scoped set for a narrow STS credential task (get single, get all, update). It is slightly thin, but each tool earns its place with no obvious padding.
The set covers the core lifecycle of viewing credential info and refreshing/updating STS credentials. A delete or explicit refresh/validation operation is absent, but agents can work around this for the stated purpose.
Credential broker for AI agents: scoped, revocable API access with policy enforcement and audit.
Encrypted secret store and rotation for autonomous agent credentials
Credential isolation for AI agents: placeholder secrets, policy checks, optional human approval.
Issue, rotate and revoke scoped API-key passes for 25+ providers — the agent never sees a real key
