> [!NOTE] Use the legacy SSE transport > I'll walk you through the difficulties I had getting an MCP server running over HTTP instead of `stdio`, which is still the default adopted by the ecosystem. > The main learning is that you should _not yet_ use the updated ["Streamable HTTP" protocol](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http), and instead use the legacy ["HTTP with SSE" protocol](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports#http-with-sse). I wanted to revisit the idea of connecting an LLM to Obsidian for fun and profit. Here's the idea: > An AI should be able to operate Obsidian for you. This Obsidian is a essentially a highly extensible text editor. This makes it an ideal automation target for the smarter variety of LLMs. Briefly, here's the case for automation in your personal knowledge graph: - Extend the software. Obsidian is extensible, but relatively few of us know the extension APIs inside and out. It would be great if the AI could extend the app for you. - Act as digital librarian. Sometimes I find myself wondering "where was that note about..." and unable to find it. Let the LLM act as your agent and search through your notes. - Content automation. For example, have Claude Code write DataViews for you using the data-view plugin. There's no need for Claude Code to author your journal entries, but there are still some tasks that an LLM is better suited for. # The latest spec is _unsupported_ This one really threw me off. Neither Claude Code, nor Claude Desktop, support the latest version of the MCP. What?! I spent far too much time wondering why my implementation wasn't working with these tools, just to find out later that they don't support the MCP version I was using. The latest version as of this writing is here: https://modelcontextprotocol.io/specification/2025-03-26/basic/ However, the "Streamable HTTP" transport described [in that doc](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http) is not supported by either Claude Code or Claude Desktop. By adhering to the latest version of the spec I was building an integration that was destined to fail. # Claude Desktop doesn't support HTTP transport at all Another surprise, slightly different. Once I figured out I needed to use the [legacy transport protocol](https://modelcontextprotocol.io/specification/2024-11-05/basic/transports#http-with-sse) Claude Code started working perfectly, however, Claude Desktop as completely unable to launch with the following config: ```json { "mcpServers": { "obsidian": { "url": "http://localhost:22360/sse", "env": {} } } } ``` It turns out a workaround was needed. Claude Desktop needs a workaround. Luckily, the devs at CloudFlare created an adapter that turns a remote HTTP API into a `stdio` API. Here's the config that works with Claude Desktop as of [[2025-06-09]]: ```json { "mcpServers": { "obsidian": { "command": "npx", "args": ["mcp-remote", "http://localhost:22360/sse"], "env": {} }, } } ``` In the end it works perfectly, but I've definitely jumped in a bit early. The ecosystem has not had a chance to reach a stage where most things are documented. # How do I verify the MCP server? The most significant difficulty in creating this MCP server was verifying that it worked. My initial thinking was that I'd simply use an existing MCP client, such as Claude Code, Claude Desktop, or Cursor. However, _not one_ of these worked as expected. In addition to the issues described above with the Claude products, Cursor was able to connect to the server using the most recent protocol but wasn't able to make any tool calls. Cursor said "connected" and correctly listed the available tools, a sure sign it really was connected, but I couldn't get it to make any tool calls. Asking it directly to call MCP tools didn't help. Perhaps there is a bug that keeps the AI from seeing what tools are available in Cursor. All of this is to say that there was no clear answer to "when is it done", because various tools didn't work as expected. # Claude Code IDE Integration Claude Code has a relatively new feature where it can automatically get context on what you're doing in your IDE. Specifically: - The currently opened file - The currently selected line numbers I think that's it, but still, that's not nothing. If you want Claude to act on your current file it's quite convenient to have it already aware of the file path. This is a completely undocumented feature that someone from the Neovim community reverse engineered in order to use NVIM as their IDE with Claude. You can find out more about their efforts here: https://github.com/coder/claudecode.nvim (also, that Github username...) Without that project I likely wouldn't have tried to get IDE integration working with Obsidian, but since there was a proof of concept out there I decided to go for it. # Why bother? I like the idea of software with an intended userbase of 1, i.e. you. Software that is tailored to your needs specifically, and no one else's. This project is an experiment in that direction. Given the right context LLMs can get a lot done. Obsidian, being fundamentally a web browser with some note-taking features, is capable of being exactly what any user wants it to be. Even those of us with the expertise to write code don't necessarily have the time or patience to get familiar with the API and build something on top of it. This is my _second_ experiment in this direction. The first was [Vibesidian](https://github.com/iansinnott/vibesidian), an AI agent that can operate Obsidian on your behalf. In that case I wrote the agent system from scratch, however, Claude Code is an undeniably more advance and more mature coding agent, so I thought it made sense to try to integrate it with Obsidian as an alternative to Vibesidian.