When Dependencies Break at 9pm: A FastMCP Story

July 2, 2025

Last night at 9pm CT, a user reported that they couldn’t connect their MCP server to Claude Desktop. The error logs showed “Unexpected token ’╭’” and a cascade of ”… is not valid JSON” errors. Within minutes, we discovered this wasn’t just affecting one MCP server - both of our open source MCP servers (Basic Memory and open-ghl-mcp) were experiencing the same issue.

The Timeline

9:01 PM CT - First user report comes in via Discord. They were trying to connect an MCP server and getting JSON parsing errors.

9:08 PM CT - I checked our own projects. Both open-ghl-mcp and Basic Memory were showing identical symptoms. The MCP servers were starting but immediately failing with JSON parsing errors.

9:15 PM CT - Dove into the logs. Found something unusual - decorative ASCII box drawing characters (╭, │, ╰) appearing in what should be pure JSON output.

9:22 PM CT - Traced the issue to FastMCP v2.10.0, released earlier that day. The new version was outputting decorative borders to stdout, breaking the JSON-based MCP protocol.

9:45 PM CT - Filed issue #1010 with FastMCP to alert the community.

10:30 PM CT - Pushed PR #203 pinning FastMCP to versions below 2.10.0.

10:55 PM CT - Released Basic Memory v0.14.1 with the fix.

The Technical Details

The Model Context Protocol (MCP) relies on clean JSON communication between servers and clients. When FastMCP v2.10.0 added decorative ASCII box drawing to stdout, it broke this contract:

╭─────────────────────────────────────────╮
│  FastMCP Server Starting...             │
╰─────────────────────────────────────────╯
{"jsonrpc": "2.0", "method": "initialize"}

Clients like Claude Desktop saw those box drawing characters and threw JSON parsing errors. The result? Complete failure of MCP server functionality.

The Fix

The immediate fix was straightforward - pin FastMCP to a working version:

# In pyproject.toml
dependencies = [
    "fastmcp>=2.3.4,<2.10.0",  # Constrained to prevent breaking change
    # ... other dependencies
]

Lessons Learned

Dependencies can break at any time - Even well-maintained projects can introduce breaking changes. Having monitoring and rapid response procedures is crucial.
Community matters - Within 2 hours, we had identified the issue, created a fix, filed an upstream bug report, and released a patch. This was only possible because users reported the issue quickly and clearly.
Pin strategically - While we generally prefer flexible version constraints, critical infrastructure dependencies sometimes need upper bounds to prevent breaking changes.
Unit testing is important – When a lot of people depend on your code, don’t rush. Unit tests are essential, but thoughtful, careful releases matter even more. Take your time and get it right.

Moving Forward

We’ve added explicit version constraints for FastMCP until the upstream issue is resolved. The FastMCP team is aware of the issue, and we expect they’ll address it soon.

For Basic Memory users, simply upgrade to v0.14.1:

# Using uv (recommended)
uv tool upgrade basic-memory

# Using pip
pip install --upgrade basic-memory

# Using Homebrew
brew upgrade basic-memory

Thank You

Special thanks to the user who provided the quick and detailed bug report. This is what makes open source amazing - users who care enough to report issues clearly, maintainers who jump on fixes immediately, and a community that works together to keep things running.

If you encounter issues with Basic Memory or any of our tools, please don’t hesitate to reach out. You can find us at @basicmachines-co on GitHub, and file issues directly on the Basic Memory repository.

Follow Up

FastMCP reverted the change in a hot fix very quickly also. Sometimes clever ideas have unintended consequences.

Basic Memory is local-first knowledge management for AI. It lets you build a personal knowledge graph that AI assistants can navigate, search, and extend. Learn more →