Repository navigation
[Bug]: Docker server fails to boot after mcp 2.0.0 release — mcp_bridge uses the removed v1 low-level API #2147
Description
crawl4ai version
Docker server (deploy/docker), requirements.txt as of today (mcp>=1.18.0).
Expected Behavior
The Docker server boots and exposes the API, with the MCP layer at /mcp/sse, /mcp/ws, /mcp/schema.
Current Behavior
A fresh build/install now fails to start the server. The mcp Python SDK released v2.0.0 on 2026-07-28, and deploy/docker/requirements.txt pins mcp>=1.18.0 with no upper bound, so a fresh pip install -r deploy/docker/requirements.txt resolves mcp==2.0.0. The v2 low-level API removed the Server.list_tools/call_tool/list_resources/read_resource/list_resource_templates decorator helpers that deploy/docker/mcp_bridge.py uses, so attach_mcp() crashes at import time:
AttributeError: 'Server' object has no attribute 'list_tools'server.py calls attach_mcp(app, ...) at module level (line ~1092), so uvicorn server:app fails on boot. .github/workflows/security.yml installs the same requirements, so CI is broken too.
Steps to Reproduce
pip install "mcp==2.0.0" fastapi uvicorn httpx anyio pydantic PyJWT
python - <<'PY'
import os, sys
sys.path.insert(0, "deploy/docker")
os.environ["CRAWL4AI_API_TOKEN"] = "x"
from fastapi import FastAPI
from mcp_bridge import attach_mcp
app = FastAPI()
attach_mcp(app, base_url="http://127.0.0.1:8020")
PYOutput: AttributeError: 'Server' object has no attribute 'list_tools'.
With pip install "mcp==1.18.0" the same code works and the MCP SSE handshake completes.
Root Cause
mcp>=1.18.0indeploy/docker/requirements.txthas no upper bound.- mcp v2.0.0 (https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.0.0) removed the v1 low-level
Serverdecorator API used bymcp_bridge.py. The v2 release notes explicitly tell non-migrated projects to keep a<2upper bound.
Suggested Fix
Add the <2 ceiling to the requirement (as the mcp SDK maintainers recommend for projects not yet migrated to v2):
- mcp>=1.18.0
+ mcp>=1.18.0,<2A proper migration of mcp_bridge.py to the v2 low-level API can be done separately.
Activity
NG-PR0JECT commentedon Aug 20, 2026
Verified against
mcp==2.0.0— your diagnosis checks out exactly. Confirmed:from mcp.server.lowlevel.server import Serverstill imports on 2.0.0 (the class is kept, now@deprecated), but the handler-decorator surfacemcp_bridge.pyrelies on is gone:Server.list_tools / call_tool / list_resources / read_resource / list_resource_templatesand theadd_*helpers no longer exist — hence theAttributeErroratattach_mcp()time.mcp.server.mcpserver.MCPServerwith@tools/@resources/@promptsbinding decorators (ToolBinding / ResourceBinding / MethodBinding) plus a newrunner/dispatcher layer (mcp.server.runner). So a v2 migration is not a decorator 1:1 swap — it is a rewrite against MCPServer. Worth tracking as a separate change, not blocking the boot fix.Agree the
<2ceiling is the right immediate fix (mcp>=1.18.0,<2). One note:.github/workflows/security.ymlinstalls the same requirements, so that single change unblocks both the Docker boot and CI in one commit.nightcityblade commentedon Aug 20, 2026
Hi, I'd like to work on this. I'll submit a PR shortly.
nightcityblade commentedon Aug 20, 2026
I’m withdrawing my claim so I don’t block anyone. The dependency ceiling resolves correctly and the bridge smoke test passes, but the current relevant MCP regression suite has a pre-existing contradictory failure (
test_issue_1594_mcp_sse.pyexpects the old function handler whiletest_issue_1850_mcp_sse.pyrequires the newer callable-class handler). I won’t submit while that focused suite is red.nightcityblade commentedon Oct 8, 2026
I’m re-checking this against the current develop branch now that the MCP regression suite may have moved on. If the focused suite is green, I’ll submit the dependency ceiling fix shortly; otherwise I’ll report and step back again.
nightcityblade commentedon Oct 8, 2026
Update: current
developalready pinsmcp>=1.18.0,<2indeploy/docker/requirements.txt, so the requested boot fix is present and a new PR would be redundant. I’m stepping back again; this issue can likely be closed after release verification.