aws-agent-toolkit: accept AWS access keys as saved credentials

[bsmitches]

Summary

Follow-up to #22. Declares the three standard AWS credential env vars on the aws-agent-toolkit server so a user with no shared config, SSO session or instance role can supply keys through the plugin:

"AWS_ACCESS_KEY_ID": "${AWS_ACCESS_KEY_ID:-}",
"AWS_SECRET_ACCESS_KEY": "${AWS_SECRET_ACCESS_KEY:-}",
"AWS_SESSION_TOKEN": "${AWS_SESSION_TOKEN:-}"

AWS_MCP_PROXY_PROFILES and AWS_REGION are unchanged, and the description now explains that keys must be set as a pair and that they take precedence over any profile.

Why the ${NAME:-} form matters here

All three use the empty-default form rather than a bare ${NAME}. This is not cosmetic. botocore's EnvProvider gates on a truthy access key, not a valid one:

access_key = self.environ.get(self._mapping['access_key'], '')
if access_key:
    logger.info('Found credentials in environment variables.')

So an empty value falls through to the rest of the chain, but an unsubstituted literal ${AWS_ACCESS_KEY_ID} would be treated as a real access key. I tested that case against the live endpoint: the tool call fails with failed due to expired or invalid AWS credentials and does not fall back to the shared-config credentials that were working a moment earlier. The empty-default form removes that exposure entirely.

Test evidence

Carried over from the testing done on #22, against the real https://aws-mcp.us-east-1.api.aws/mcp endpoint (initialize + tools/call running sts:GetCallerIdentity):

Env state	Result
All credential vars empty	Succeeds — falls through to shared config / aws login session
Complete but invalid keys	Fails with a clear invalid AWS credentials message, confirming the env provider is consumed and takes precedence over the profile
Bare ${AWS_ACCESS_KEY_ID} literal	Fails and shadows the working chain — the case this form avoids

One sharp edge worth knowing, also measured: setting AWS_ACCESS_KEY_ID without AWS_SECRET_ACCESS_KEY does not fall through and does not report a credential error — the proxy comes up with no tools and reports Unknown tool: 'aws___run_script'. That is upstream behaviour in mcp-proxy-for-aws, not something this manifest can guard, which is why the description tells users to set the two together.

Not exercised, since the test machine has no such credentials: SSO, EC2/ECS instance roles, web identity, process credentials. They ride the same boto3.Session() as the tested sources.

Test plan

• python3 scripts/validate.py → ok: 171 entries (170 authored, 1 upstream)
• python3 scripts/validate.py --fetch → all pinned upstream shas resolve
• Each env value is a plain ${<OWN_KEY>} placeholder matching its own env key; no credential values checked in

Generated with Devin

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review