v1.8.6

[naveenraj-17]

v1.8.6 — Critical fix: MCP tools broken on new installs

⚠️ If you installed or upgraded Synapse on or after 28 July 2026, you were affected

Symptom: no native tools in the "Create Agent" settings, and MCP servers failing to connect. Startup logs showed:

AttributeError: 'Server' object has no attribute 'list_tools'
  Warning: Failed to connect agent 'time': Connection closed
  Failed to connect native MCP server 'Memory': unsupported operand type(s) for +: 'float' and 'datetime.timedelta'

This was our bug, not yours. Nothing you did caused it, and no reinstall, config change, or fresh setup would have fixed it. We're sorry — for roughly the last two weeks, every new install and every synapse upgrade produced a Synapse with no working tools at all.

Fix it now:

synapse upgrade
# or
pip install --upgrade synapse-orch-ai==1.8.6
# or
npm install -g synapse-orch-ai@1.8.6

Then restart Synapse. Your agents, orchestrations, and data are untouched — this only affects the tool layer, and it recovers completely on restart.

---

What happened

The mcp Python SDK released 2.0.0 on 28 July 2026, a breaking rewrite. Synapse declared mcp with no upper version bound, so from that day on every fresh install resolved 2.0.0 and hit two incompatibilities:

1. The low-level Server decorator API was removed. All 11 native tool servers (time, sql, bash, file_reader, pdf_parser, web_scraper, vault_sandbox, code_vault_search, and others) register handlers with @app.list_tools(). Every one of them crashed at import, so the tool router came up empty — hence no tools in the UI.

2. ClientSession(read_timeout_seconds=...) changed from timedelta to float. This broke the Filesystem, Browser Automation, Memory, and Sequential Thinking MCP servers.

The backend logged each failure as a warning and started anyway, which is why it looked healthy while being entirely non-functional.

Why our CI didn't catch it: the test suite never actually started a tool server. It installed the same broken dependency set and stayed green. That gap is closed below.

Fixes

• mcp pinned to >=1.29,<2. 1.29.0 shipped the same day as 2.0.0 as the supported 1.x line, and needs no code changes.
• Every dependency now carries an upper bound, in both pyproject.toml (the pip install path) and backend/requirements*.txt.
• New backend/requirements.lock — 181 exact pins covering the full transitive tree, valid across Python 3.11–3.14 on Linux/macOS/Windows. The CLI, setup.py, all Docker images, and CI now install from it, so everyone gets the environment we actually tested.

Python 3.14 support

Now supported on Linux, Windows, and Apple Silicon Macs (macOS 14+). requires-python is >=3.11,<3.15, and installers detect and prefer 3.14 where it works.

Known limitation: Python 3.14 does not work on Intel Macs — onnxruntime (a chromadb dependency) publishes no x86_64 macOS wheel for 3.14. The installers automatically prefer Python 3.13 on macOS and warn if you force 3.14. Use 3.13 on Intel Macs.

Preventing a repeat

• test_mcp_tool_servers.py — boots all 11 tool servers over stdio and lists their tools. Verified to fail 11/11 against mcp 2.0.0, so it genuinely catches this class of bug.
• test_mcp_sdk_contract.py — asserts the exact SDK surface we depend on, naming the breakage in one line.
• test_requirements_pinned.py — fails the build if any dependency loses its upper bound.
• Nightly dependency-drift job — deliberately resolves dependencies unpinned and boots every tool server. The next upstream break shows up as a nightly failure to us, not a broken install for you.
• CI now runs Python 3.11–3.14 and verifies the lockfile stays in sync.

What's next: mcp 2.0

We're staying on mcp 1.x deliberately, not permanently. 2.0 has real value we want — a first-class Client, protocol revision 2026-07-28, multi-round-trip tools, caching hints, middleware, and OAuth/stdio security hardening.

But migrating means rewriting all 11 tool servers, and 2.0 removes automatic input validation — handlers must validate themselves. That lands squarely on bash, sandbox, and file_reader. We're not rushing that into a hotfix. The migration will land as its own release with the security-sensitive parts properly reviewed.

---

Full changelog: v1.8.5...v1.8.6

---

This discussion was created from the release v1.8.6.