fix(deps): bump mcp to 1.30.0 and remediate FOSSA CVEs in samples and testcases - #249
Conversation
There was a problem hiding this comment.
🔵 Needs a closer look
The dependency updates span SDK, samples, testcases, and lockfiles, warranting final human approval.
Pull request overview
Updates MCP and LangGraph dependencies to remediate reported CVEs while retaining MCP 1.x compatibility.
Changes:
- Bumps
uipath-mcpto0.3.1and MCP to1.30.0. - Raises testcase MCP floors to
>=1.28.1. - Raises agent sample LangGraph floors to
>=1.0.10and refreshes locks.
File summaries
| File | Description |
|---|---|
uv.lock |
Refreshes SDK dependency locks. |
testcases/string-server/pyproject.toml |
Raises the MCP minimum version. |
testcases/ground-to-cloud/pyproject.toml |
Raises the MCP minimum version. |
testcases/datetime-server/pyproject.toml |
Raises the MCP minimum version. |
samples/mcp-functions-agent/pyproject.toml |
Raises the LangGraph minimum version. |
samples/github-slack-agent/pyproject.toml |
Raises the LangGraph minimum version. |
samples/github-helper-agent/pyproject.toml |
Raises the LangGraph minimum version. |
pyproject.toml |
Updates the SDK version and MCP pin. |
Review details
- Files reviewed: 7/11 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.
robert-ursu
changed the title
… testcases mcp moves from 1.26.0 to 1.30.0, the last 1.x release, which covers CVE-2025-66416, CVE-2026-52869 and CVE-2026-59950. The three agent samples are re-locked with langgraph 1.x and mcp 2.0.0 and the testcase mcp floors are lifted to 1.28.1. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
uipath moves from >=2.10.40, <2.14.0 to >=2.14.16, <2.15.0 so installs pick up the click, PyJWT, python-dotenv and python-socketio fixes shipped in UiPath/uipath-python#1897. uipath 2.14 requires uipath-runtime 0.13, so that range follows to >=0.13.1, <0.14.0. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
05b294b to
a6837fe
Compare
Freshly published uipath releases are blocked by the runner's safe-chain guard until they age, which fails uv sync on the first CI run after a release. Mirrors the exemption already used in uipath-langchain-python. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
radugheo
left a comment
radugheo
left a comment
There was a problem hiding this comment.
Local review of the dependency bumps. SDK side is clean (mypy, ruff and 203 tests pass on mcp 1.30.0 / uipath 2.14.16). Three notes inline.
| dependencies = [ | ||
| "uipath-langchain>=0.0.118", | ||
| "langgraph>=0.5.4", | ||
| "langgraph>=1.0.10", |
There was a problem hiding this comment.
This lock also moves mcp to 2.0.0, which breaks all three agent samples at import. 2.0.0 drops mcp.server.fastmcp, imported at module load by langchain-mcp-adapters 0.3.1, and renames streamablehttp_client to streamable_http_client. Both are used by the samples.
Verified by syncing each lock on Python 3.11 and importing the entrypoint: clean on main, failing here.
Suggest adding "mcp>=1.28.1,<2" here and re-locking, keeping the samples on the same 1.x line the SDK chose. Confirmed that mcp 1.30.0 imports clean alongside langchain 1.4.0, adapters 0.3.1 and langgraph 1.2.11.
There was a problem hiding this comment.
Right on the breakage, but mcp>=1.28.1,<2 is not resolvable: every uipath-langchain since 0.17 pins mcp==2.0.0, and the releases before that pin mcp==1.26.0 (vulnerable), so with that cap uv backtracked uipath-langchain to 0.1.31. langchain-mcp-adapters also caps mcp<2, so the adapter cannot ride along either.
Fixed in 66e2729 by staying on mcp 2.0.0 and porting the samples to the SDK helpers: uipath_langchain.agent.tools.mcp.load_mcp_tools and streamable_http_client, with a small mcp_session helper passing the bearer token through an httpx2.AsyncClient. langchain-mcp-adapters is dropped, uipath-langchain floored at 0.17.0 where those helpers landed. All three entrypoints import cleanly after uv sync on 3.11.
| dependencies = [ | ||
| "uipath-langchain>=0.0.118", | ||
| "langgraph>=0.5.4", | ||
| "langgraph>=1.0.10", |
There was a problem hiding this comment.
Re-locking here also pulls langchain 1.4.0 through the uipath-langchain 0.0.118 -> 0.18.0 jump that the unchanged >=0.0.118 floor allows, and 1.4.0 removed langchain.output_parsers. That breaks main.py:8 in this sample and builder.py:5 in mcp-functions-agent.
Both files import fine on main and fail here. This line fires before the mcp one, so fixing only the mcp pin still leaves these two broken.
Fix: from langchain_core.output_parsers import PydanticOutputParser, which is present in langchain-core 1.6.3.
There was a problem hiding this comment.
Fixed in 66e2729: both files now import PydanticOutputParser from langchain_core.output_parsers.
| [project] | ||
| name = "uipath-mcp" | ||
| version = "0.3.0" | ||
| version = "0.3.1" |
There was a problem hiding this comment.
The five server samples still lock vulnerable mcp, 1.9.0 in mcp-longrunning-server and 1.11.0 in the other four. Their uipath-mcp>=0.0.101 floors already permit 0.3.1, so a re-lock once it publishes is all that is needed.
There was a problem hiding this comment.
Agreed, that is the plan. The five server-sample locks are left untouched here and will be re-locked once 0.3.1 is on PyPI, since their mcp comes transitively from the published uipath-mcp.
Re-locking the three agent samples pulled langchain 1.4.0 and mcp 2.0.0, which removed langchain.output_parsers, mcp.server.fastmcp and the streamablehttp_client name, so the entrypoints no longer imported. langchain-mcp-adapters caps mcp below 2.0 and every uipath-langchain since 0.17 pins mcp==2.0.0, so the samples drop the adapter and use uipath_langchain.agent.tools.mcp (load_mcp_tools, streamable_http_client) instead, with a small mcp_session helper carrying the bearer token via an httpx2 client. Verified by syncing each sample on Python 3.11 and importing its entrypoint. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Summary
Remediates the FOSSA security findings for the SDK, its samples and its testcases.
==1.30.0; agent sample locks 2.0.0; testcase floors>=1.28.1>=1.0.10, locked 1.2.11The three agent samples (
github-helper-agent,github-slack-agent,mcp-functions-agent) are ported to the SDK MCP helpers. Their re-lock lands on langchain 1.4.0 and mcp 2.0.0, which removedlangchain.output_parsers,mcp.server.fastmcpand thestreamablehttp_clientname, so the entrypoints stopped importing. Cappingmcp<2is not an option: everyuipath-langchainsince 0.17 pinsmcp==2.0.0, andlangchain-mcp-adapterscapsmcp<2. The samples therefore drop the adapter and useuipath_langchain.agent.tools.mcp(load_mcp_tools,streamable_http_client) behind a smallmcp_sessionhelper, withuipath-langchainfloored at 0.17.0. Each entrypoint imports cleanly afteruv syncon Python 3.11.uipath-mcpis bumped to 0.3.1. mcp 1.30.0 is the last 1.x release; it stays on the 1.x line rather than jumping to 2.x.uipathmoves from>=2.10.40, <2.14.0to>=2.14.16, <2.15.0so installs pick up the patched release from UiPath/uipath-python#1897. uipath 2.14 requires uipath-runtime 0.13, so that range follows to>=0.13.1, <0.14.0. The SDK lock now resolves uipath 2.14.16 / uipath-runtime 0.13.5; mypy, ruff and the test suite pass on that pair.The five server samples (
mcp-dynamic-server,mcp-functions-server,mcp-longrunning-server,mcp-math-server,mcp-sdk-server) takemcptransitively from the publisheduipath-mcp, which pins 1.26.0. Their lockfiles cannot move past 1.26.0 until 0.3.1 is on PyPI, so they are left untouched here and need a follow-up re-lock after this ships.The workflows also gain the
SAFE_CHAIN_MINIMUM_PACKAGE_AGE_EXCLUSIONSenv already used in uipath-langchain-python: the runner's safe-chain guard blocked the hour-old uipath 2.14.16 wheel and faileduv syncon every job.Verification
mypy,ruff check,ruff format --checkpasspytest: 203 passed🤖 Generated with Claude Code