Repository navigation
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.
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 pull request is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon. If you wish to exclude this issue from being marked as stale, add the "backlog" label. |
|
Still relevant: main still launches mcp-proxy-for-aws@latest in all three plugins and #255 is open. I can rebase and refresh the pinned versions whenever a maintainer is ready to look. |
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.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.