Conversation
@latest on mcp-proxy-for-aws makes uvx re-resolve the tool's full dependency tree on every invocation. mcp-proxy-for-aws itself declares botocore[crt]>=1.41.0 and boto3>=1.41.0 with no upper bound, and both packages release very frequently. Whenever a new botocore/boto3 release lands between two invocations, uv resolves a different environment and caches it as a new entry alongside every earlier one -- verified directly: pinning only the top-level package to an exact version still showed the cache growing across two different resolution windows (141M -> 205M) purely from botocore picking up a different version each time. A user reported this compounding to 138GB / ~1,250 cached environments in production (issue awslabs#255). Pinned mcp-proxy-for-aws to its current release (1.6.6) and added --with constraints for botocore[crt] and boto3 (also pinned to their current release, 1.43.93) across the three plugins that invoke it (amazon-location-service, sagemaker-ai, aws-amplify). Verified the fully-pinned combination resolves successfully and produces a stable, reused environment across repeated invocations and across different simulated resolution windows -- no further growth. The other five plugins' MCP servers (awslabs.*-mcp-server@latest) are untouched: those are AWS's own first-party servers with their own release cadence and are not affected by this specific mechanism.
mittalpk
requested review from
a team,
arnewouters,
laithalsaadoon and
rshevchuk-git
and
a lite review from Copilot
September 13, 2026 12:41
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
Transitive dependencies such as awscrt remain unpinned, so cache growth can recur.
Pull request overview
Pins mcp-proxy-for-aws and AWS SDK dependencies in three MCP plugin configurations to reduce uvx cache growth.
Changes:
- Pins
mcp-proxy-for-awsto1.6.6. - Pins
botocore[crt]andboto3to1.43.93. - Leaves unrelated AWS MCP packages unchanged.
File summaries
| File | Description |
|---|---|
plugins/sagemaker-ai/.mcp.json |
Pins proxy and SDK dependencies. |
plugins/aws-amplify/.mcp.json |
Pins proxy and SDK dependencies. |
plugins/amazon-location-service/.mcp.json |
Pins proxy and SDK dependencies. |
Review details
Suppressed comments (3)
plugins/amazon-location-service/.mcp.json:9
- These pins still leave the
uvxenvironment non-reproducible:botocore[crt]resolvesawscrt, and boto3/botocore resolve other ranged transitive dependencies. A future release of any of those packages will causeuvto create another cached environment, so the unbounded-cache problem can recur despite these three pins. Pin the complete resolved dependency set (ideally with a checked-in lock/requirements wrapper) or automate updates for every transitive dependency.
"--with",
"botocore[crt]==1.43.93",
"--with",
"boto3==1.43.93",
"mcp-proxy-for-aws==1.6.6",
plugins/aws-amplify/.mcp.json:9
- These pins still leave the
uvxenvironment non-reproducible:botocore[crt]resolvesawscrt, and boto3/botocore resolve other ranged transitive dependencies. A future release of any of those packages will causeuvto create another cached environment, so the unbounded-cache problem can recur despite these three pins. Pin the complete resolved dependency set (ideally with a checked-in lock/requirements wrapper) or automate updates for every transitive dependency.
"--with",
"botocore[crt]==1.43.93",
"--with",
"boto3==1.43.93",
"mcp-proxy-for-aws==1.6.6",
plugins/sagemaker-ai/.mcp.json:10
- These pins still leave the
uvxenvironment non-reproducible:botocore[crt]resolvesawscrt, and boto3/botocore resolve other ranged transitive dependencies. A future release of any of those packages will causeuvto create another cached environment, so the unbounded-cache problem can recur despite these three pins. Pin the complete resolved dependency set (ideally with a checked-in lock/requirements wrapper) or automate updates for every transitive dependency.
"--with",
"botocore[crt]==1.43.93",
"--with",
"boto3==1.43.93",
"mcp-proxy-for-aws==1.6.6",
- Files reviewed: 3/3 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #255.
Root cause
mcp-proxy-for-aws@latest(viauvx) doesn't just re-check the top-level package on each launch — it re-resolves the entire dependency tree.mcp-proxy-for-awsdeclaresbotocore[crt]>=1.41.0andboto3>=1.41.0with no upper bound (checked its published metadata), and both AWS SDK packages release very frequently (multiple times a month). Whenever a newerbotocore/boto3release exists on PyPI at launch time,uvresolves a different set of packages and caches it as a brand-new environment — the old one is never cleaned up.I verified this isn't just a top-level-version problem: even with
mcp-proxy-for-awspinned to an exact version andbotocore/boto3left unpinned, resolving at two different points in time (viauv's--exclude-newer, to simulate real time passing between sessions) produced two differentbotocoredownloads and grew the cache from 141M to 205M. Fully pinningmcp-proxy-for-awsandbotocore[crt]/boto3together resolved successfully and stayed byte-for-byte stable (145M, no growth) across repeated invocations and across different simulated resolution windows.This matches the reporter's observation: ~1,250 accumulated environments, 138GB, reclaimed by a manual
uv cache clean.Fix
Pinned
mcp-proxy-for-awsto its current release (1.6.6) and added explicit--with botocore[crt]==1.43.93/--with boto3==1.43.93constraints, in the three plugins that invoke it directly:amazon-location-service,sagemaker-ai,aws-amplify.The other five plugins (
deploy-on-aws,aws-serverless,databases-on-aws,aws-transform,codebase-documentor-for-aws) invoke AWS's own first-partyawslabs.*-mcp-serverpackages via@latest— a different package family with its own release cadence, not affected by this specific mechanism, and left untouched.Tradeoff, flagged for maintainer judgment
This trades unbounded cache growth for a version that needs periodic manual bumping (
mcp-proxy-for-aws,botocore,boto3) as new releases ship. I didn't see a Dependabot/Renovate config that tracks Python version strings embedded in.mcp.jsonargsarrays — happy to add one if there's a preferred mechanism, but didn't want to introduce new tooling unprompted (perCLAUDE.md's "never add new dependencies without asking first").How did you test it
This is an environment/config fix, not application logic, so there's no automated regression test to add — I verified the underlying
uvcaching mechanism directly:mcp-proxy-for-aws's published dependency metadata (botocore[crt]>=1.41.0,boto3>=1.41.0, no upper bound).--exclude-newercutoffs grew the cache (141M → 205M) with genuinely differentbotocoredownloads each time.mcp-proxy-for-aws==1.6.6+botocore[crt]==1.43.93+boto3==1.43.93) resolves successfully, runs correctly (confirmed--helpoutput and a real stdio server startup against the actual endpoint URL), and produces zero cache growth across repeated invocations and across different simulated time windows.python3 -m json.toolon all 3 changed files: valid.npx ajv-cli validate -s schemas/mcp.schema.json -d 'plugins/**/.mcp.json': all 8.mcp.jsonfiles (including the 3 changed ones) valid against the repo's own schema.