[FEATURE] Support credential (re)sourcing at any point in the MCP server lifecycle #688

Summary

Credentials are resolved once, at provider auth initialisation, from the process environment block inherited at spawn. There is no way to supply or refresh credentials after the server process has started. This makes the MCP server unusable in host environments that do not pass credentials through at spawn time, and makes it fail permanently when short-lived credentials expire mid-session.

Proposal: add an MCP tool that (re)sources credentials from a source of truth that can change independently of the process environment block, and re-initialises provider auth without a process restart.

Motivating case

Claude Desktop spawns the MCP server as an MCPB extension subprocess. The server binary receives whatever environment block the host constructs for it. AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY set at Windows User scope did not reach the process.

Observed:

credentials error: credentialsenvvar references empty string

Ruled out during diagnosis:

• Credentials unset. Both read back correctly via [Environment]::GetEnvironmentVariable(..., "User").
• Wrong variable names. aws_signing_v4 defaults to AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY.
• Stale process. Confirmed spawn times after restart; parent PID is the Claude Desktop process.
• Wrong user context. Invoke-CimMethod -MethodName GetOwner returns LAPTOP25\javen.
• Provider not installed. pull_provider succeeded (aws v26.07.00414).

The user has no remedy. The server is running, healthy, correctly configured, and cannot be given a credential by any means short of killing it.

Why re-sourcing the environment block is not sufficient

A process environment block is a copy taken at creation. Windows does not update it for a running process, which is why setx has no effect on already-open terminals. A tool that re-reads os.Getenv would read the same static block and return the same empty string.

For a reload to reload anything, it has to read from something mutable relative to the process:

1. Values passed as tool arguments. Works everywhere, no platform-specific code, but places credential material in the MCP message path.
2. A credentials file or profile re-read from disk. Keeps secrets out of the message path and out of the manifest. For AWS this is ~/.aws/credentials plus AWS_PROFILE, which also solves STS refresh, since the SDK rewrites the file.
3. An explicit OS-level environment lookup (registry on Windows, /proc/<pid>/environ semantics elsewhere). Platform-specific, and still will not see a value the host never wrote.

Option 2 looks strongest for AWS specifically. Option 1 generalises across the 60+ providers, each with different auth shapes.

Proposed interface

A tool, gated by server mode, roughly:

reload_credentials(provider?: string) -> {provider, auth_type, status, sourced_from}

Behaviour:

• With provider set, re-initialise auth for that provider only. Without, re-initialise all initialised providers.
• Report which source each credential resolved from, and whether resolution succeeded, without echoing the credential value.
• Fail loudly on a provider whose auth cannot be resolved rather than deferring to the next query.

Open questions:

• Where are resolved auth contexts cached, and what is the invalidation path? If auth is bound into a provider handle at first use, this needs an explicit teardown rather than a re-read.
• Interaction with mode and is_read_only. A credential reload is not a read, and arguably should be unavailable in a read-only server.
• Concurrency. In-flight queries against a provider whose auth is being swapped.
• Whether a failed reload should leave prior working auth intact or clear it.

Expiry case

Independent of the host problem. STS session tokens are typically an hour. A long-lived MCP session outlives them, and today the only recovery is a process restart, which for an MCPB extension means a full Claude Desktop restart. Sourcing from a credentials file that the AWS SDK refreshes in place handles this without a tool call at all.

Alternatives considered

• Declare user_config in the MCPB manifest and map it into mcp_config.env. This is the correct fix for the Claude Desktop distribution path and should be done regardless. It does not address expiry, does not help hosts that lack an equivalent mechanism, and requires a repack and reinstall per credential change.
• Document that credentials must be present at spawn. Accurate, and leaves the expiry case unsolved.