Seoul Labs

Error: connection to MCP server timed out after 30000ms was the first line on screen after I followed the popular writeup on wiring a local model into Obsidian. Yet the same setup went on to tag a client project across a 4000 note vault in what some accounts describe as just a few minutes. The walkthroughs treat the API key and schema as trivial config, but in practice a stale or placeholder key lets LM Studio show a green connected status while every tool call fails silently, and the model starts hallucinating note contents instead of reading them. So the real question isn't whether this beats ChatGPT and NotebookLM in the abstract. It's which specific tasks survive a laptop fan spinning at full speed and a 401 error that never surfaces in the chat window.

Docker Desktop 4.43 shipping an MCP Toolkit tab changed how many people are trying this right now. The claim going around, that a local model connected to your Obsidian vault through MCP outperforms NotebookLM and ChatGPT combined, is the kind of thing I had to test myself before repeating to anyone.

Short version: it's genuinely good for a specific kind of work. Note retrieval, cross linking, and vault reorganization all hold up well. It won't replace either cloud tool in the ways people are implying, though. The comparison sounds cleaner in a blog post than it behaves on a Tuesday afternoon with a 4000 note vault and a laptop fan that will not stop spinning. Here's why, starting with what the setup actually looks like.

The Setup Behind The Obsidian MCP Connection

A widely shared walkthrough of this exact stack surfaced a few weeks ago, and it's where most of the current confusion traces back to. MCP, Model Context Protocol, is not an Obsidian feature. It's a general spec for letting a model call tools instead of just generating text. Obsidian support comes from a community MCP server. Most people are running the one distributed through Docker Desktop's MCP Toolkit or the standalone obsidian-mcp-tools plugin from the community plugin browser. Those are not the same project, and mixing them up is where half the setup confusion online starts.

The practical shape of it: you install LM Studio, then pull down a model that supports tool calling. GGUF quantized versions of Qwen2.5 or Llama 3.1 8B are common picks because they fit on consumer GPUs. Then you connect that model to an MCP client. Docker's toolkit added a Clients tab specifically so LM Studio shows up as a one click connection target rather than something you hand configure in a JSON file.

Here's what the LM Studio side of the connection config looks like once Docker writes it for you:

{
  "mcpServers": {
    "obsidian": {
      "command": "docker",
      "args": ["mcp", "gateway", "run"],
      "env": {
        "OBSIDIAN_VAULT_PATH": "/Users/name/Documents/MainVault",
        "OBSIDIAN_API_KEY": "local-rest-api-key-here"
      }
    }
  }
}

The API key line is easy to skip past, and it's the thing that breaks most first attempts. The Obsidian Local REST API plugin, which the MCP server depends on to actually touch your files, generates that key inside Obsidian itself, under its own settings pane, not inside Docker or LM Studio. Paste a placeholder or an old key after regenerating it, and the server starts, LM Studio shows it as connected, and every tool call still fails silently or returns a 401 that never surfaces in the chat window. You find out something's wrong only because the model starts hallucinating note contents instead of reading them, the exact failure mode from the opening line above.

So what does a working connection actually let the model do inside your vault?

Tasks The Local Setup Handles Well

Take a specific case. I have a vault with three years of project notes, meeting logs, and a folder of half finished blog drafts. I asked a local model with tool calling support, running through LM Studio, to find every note mentioning a client project from 2023 and tag them consistently. NotebookLM cannot do this at all. It only reads what you upload into a notebook session, has no concept of your file system, and no write access, ever. ChatGPT with a custom GPT and file uploads gets partway there, but it's working off a snapshot, not your live vault, and it cannot write anything back.

The local MCP setup completed the tagging fairly quickly in my testing, made a couple of mistakes I had to correct, and left an audit trail in Obsidian's own file history because everything happens as normal file writes.

That last part matters more than people give it credit for. Every edit the model makes is a real markdown file change, which means your existing tools still work. Git version control on the vault, Obsidian Sync, whatever backup script you already run, all keep functioning normally. NotebookLM's output lives inside Google's infrastructure. ChatGPT's memory of your files lives inside OpenAI's infrastructure. The Obsidian MCP approach never leaves your machine unless you deliberately point it at a cloud model through the same protocol.

The other place it wins is search that respects structure. Ask it to find notes linked to a specific note but not yet backlinked, and the MCP tool layer actually walks the graph:

# simplified version of what the MCP server exposes as a tool call
def find_unlinked_mentions(vault_path: str, note_title: str) -> list[str]:
    candidates = []
    for file in walk_markdown_files(vault_path):
        content = read_file(file)
        if note_title.lower() in content.lower() and f"[[{note_title}]]" not in content:
            candidates.append(file)
    return candidates

NotebookLM has nothing equivalent because it was never built around a folder of interlinked files. It was built around source documents fed into it for a single session. That's a real structural difference, not a marketing one. What happens, though, when the task requires actual reasoning depth rather than file operations?

Limits Of The Local Model Setup

Ask the same 14B model to synthesize an argument across twelve long research notes and write a two thousand word draft, and the gap with ChatGPT shows up fast. Quantized 8B and 14B models running locally are fine at retrieval, tagging, and mechanical reorganization, the strengths covered above. They're noticeably weaker at sustained multi step reasoning over long context, and Obsidian vaults full of dense technical notes push context length in ways these models were never tuned for.

I ran the same synthesis prompt through ChatGPT and through a local model via the MCP setup. The cloud model produced a coherent draft with a clear structure on the first pass. The local model produced something that read like three unconnected summaries stapled together, and it took two more rounds of prompting to reach something usable. That's not a knock on the Obsidian integration itself. The MCP layer did its job, fetching the right notes and feeding them into context correctly. The bottleneck was model capability, and no protocol fixes that.

Here's the failure mode that actually cost me time: a stale tool registration after updating the MCP server.

$ docker mcp gateway run
Error: tool 'obsidian_write_note' schema mismatch
expected: {"path": str, "content": str, "overwrite": bool}
received: {"path": str, "content": str}

The server had updated its tool schema to require an explicit overwrite flag, a sane safety change, but LM Studio had cached the old schema from the first connection and kept sending the old shape. The fix was just disconnecting and reconnecting the client in LM Studio's integration panel, but the error message gives zero hint that a stale cache is the cause. I lost twenty minutes assuming my vault path was wrong.

There's also a tradeoff nobody selling this setup mentions upfront: token generation speed on consumer hardware. A laptop with 24GB of unified memory running a 14B quantized model produces, according to some analysts and rough personal benchmarks, tokens per second that lag noticeably behind any cloud API response. For quick tagging tasks that barely registers. For a long multi note synthesis, you're watching a progress bar the way people once watched dial up downloads, and that changes how often you actually reach for the tool versus just opening ChatGPT out of habit. So is the original claim, better than NotebookLM and ChatGPT combined, actually true, or does it only hold for half the job?

The Verdict On Local MCP Versus Cloud Tools

For the narrow job of treating your notes as a live, writable, searchable graph that a model can act on directly, the local MCP setup earns the claim. Nothing in the cloud tools even attempts that job. NotebookLM was built for single session source review, and ChatGPT's file uploads are a snapshot, not a live connection to your vault.

For open ended reasoning and long form writing, the cloud models still hold a real edge that no amount of local vault access closes. A 14B model on a laptop won't outperform a frontier cloud model across twelve research notes, and pretending otherwise is how people end up disappointed by day two.

The two tools aren't actually competing for the same job, despite how the original comparison frames it. One's a file operations layer with a model attached. The other's a reasoning engine with no file system access at all. So the claim that started this, better than NotebookLM and ChatGPT combined, is really two separate claims wearing one headline: true for vault operations, false for synthesis. The 401 error that started this whole test was never a sign the idea was broken. It was a sign the idea got oversold as a single tool when it's actually two tools that haven't been wired together yet. The open question is how long before someone closes that gap by routing retrieval to a local model and the actual writing to whichever cloud model is having a good week.