Different domain but similar pattern — I hit a related wall building an MCP server for Claude Desktop (Obsidian-based memory system). Not a registry question, but adjacent: how much state the server should own vs. pass through.
The thing that bit me hardest wasn't architectural though, it was a hardcoded 60-second tool call timeout in the MCP SDK used by Claude Desktop. app.asar confirms it — no config knob to raise it. For any long-running tool (mine: extracting and summarizing a 50-page PDF) the only option is detached spawn: Phase 1 kicks off work and returns "queued" within 60s, Phase 2 runs fire-and-forget and writes results to disk for a later kioku_list call to pick up.
If your server ever does work that might exceed ~45 seconds on Desktop, worth designing that in early. Claude Code's CLI doesn't have this limit, but Desktop users will hit it.
Comments
Different domain but similar pattern — I hit a related wall building an MCP server for Claude Desktop (Obsidian-based memory system). Not a registry question, but adjacent: how much state the server should own vs. pass through.
The thing that bit me hardest wasn't architectural though, it was a hardcoded 60-second tool call timeout in the MCP SDK used by Claude Desktop. app.asar confirms it — no config knob to raise it. For any long-running tool (mine: extracting and summarizing a 50-page PDF) the only option is detached spawn: Phase 1 kicks off work and returns "queued" within 60s, Phase 2 runs fire-and-forget and writes results to disk for a later kioku_list call to pick up.
If your server ever does work that might exceed ~45 seconds on Desktop, worth designing that in early. Claude Code's CLI doesn't have this limit, but Desktop users will hit it.