Louis Tsang maintains an MCP server that generates music, and every call takes anywhere from 40 seconds to three minutes because a model is rendering audio on the other end. That single fact exposes one of Model Context Protocol's quietest assumptions: tools are meant to be called, answered, and moved past in quick succession. The transport layer is built around synchronous request/response semantics, which works fine when your tool returns JSON in milliseconds but falls apart the moment real compute gets involved.

The Sync Assumption

MCP grew up surrounded by lightweight tools โ€” file lookups, database queries, API wrappers where the heavy lifting happens elsewhere. None of those need minutes to respond. But as developers start exposing generative workloads through MCP servers โ€” audio rendering, video synthesis, image generation โ€” the protocol's synchronous shape starts to pinch hard. Tsang's music server is a textbook case: it doesn't fit "call it, get an answer, move on," and everything about the transport assumes that exact pattern.

Why This Is Everyone's Problem

This isn't just one developer with a niche hobby project hitting a wall. Every MCP server that wraps long-running model inference is going to run into this same constraint sooner rather than later. The ecosystem needs first-class patterns for async execution โ€” job IDs, polling endpoints, streaming or webhook callbacks โ€” before generative tools can become full citizens in the MCP world instead of awkward exceptions.

What Builders Can Do Today

- Return a job identifier immediately and let clients poll a status endpoint until work completes. - Expose progress as separate tool calls so agents check state without blocking on one long request. - Kick off rendering asynchronously server-side, store results, and hand back a reference to fetch later. None of these are first-class in the spec today, which means every maintainer shipping a slow MCP tool is reinventing the same pattern from scratch. That's wasted effort across the whole ecosystem.

Key Takeaways

  • MCP's synchronous request/response model assumes tools respond quickly.
  • Long-running generative workloads like music generation break that assumption and need async patterns.
  • Builders currently patch around missing spec support, but first-class async would benefit everyone.

The Bottom Line

MCP's synchronous assumptions were reasonable when tools answered in milliseconds. Music generation breaks them โ€” and it won't be the last workload to do so. Someone needs to solve async MCP properly before compute-heavy servers turn this into a recurring headache for every builder shipping real work through the protocol.