Heads-up: maintenance status and a friendly community fork

[istefox]

Hi @jacksteamdev,

Apologies in advance if I've missed any recent activity — I may well
have — but I wanted to reach out in case this is helpful.

First, a genuine thank-you for obsidian-mcp-tools. It's the project
that made a well-structured MCP integration for Obsidian feasible in
the first place, and a lot of the architecture I'm building on is
yours.

From what I can see, main hasn't had commits for several months. To
keep using the tool myself I started a small fork and slowly brought
it up to date. I'm not writing to make any claim or request — just to
open a line of communication in case you'd prefer to be looped in.

For transparency, here's what the fork currently is:

• https://github.com/istefox/obsidian-mcp-connector
• A few incremental releases (most recently 0.3.2) that mostly address
  findings from the Obsidian plugin reviewer bot and migrate away from
  the deprecated MCP SDK Server API toward McpServer.
• A community-plugin submission in progress at
  obsidianmd/obsidian-releases#11919 (automated checks pass; awaiting
  human review).

I deliberately renamed it (obsidian-mcp-connector) so there's no
confusion with your repo, and I'm happy to make the relationship with
the original project explicit in the fork's README if you'd like
specific wording.

If you're still around and ever feel like coordinating — whether
that's a small note in your README, co-maintaining, or anything else
— I'm very open to it. Equally, if you'd rather I just keep going
independently and don't need to hear more about this, that's
absolutely fine too; please feel free to close this issue.

No rush, no expectations. Just wanted the door to be open.

istefox

[jacksteamdev]

Sounds great! Question: would you be interested in joining a maintainers team? There have a couple of other inquiries in the last two weeks, maybe we can set one up so it's not such a burden on one person.

…

On Tue, Apr 21, 2026, 8:52 AM steffer ***@***.***> wrote: *istefox* created an issue (jacksteamdev/obsidian-mcp-tools#79) <#79> Hi @jacksteamdev <https://github.com/jacksteamdev>, Apologies in advance if I've missed any recent activity — I may well have — but I wanted to reach out in case this is helpful. First, a genuine thank-you for obsidian-mcp-tools. It's the project that made a well-structured MCP integration for Obsidian feasible in the first place, and a lot of the architecture I'm building on is yours. From what I can see, main hasn't had commits for several months. To keep using the tool myself I started a small fork and slowly brought it up to date. I'm not writing to make any claim or request — just to open a line of communication in case you'd prefer to be looped in. For transparency, here's what the fork currently is: - https://github.com/istefox/obsidian-mcp-connector - A few incremental releases (most recently 0.3.2) that mostly address findings from the Obsidian plugin reviewer bot and migrate away from the deprecated MCP SDK Server API toward McpServer. - A community-plugin submission in progress at obsidianmd/obsidian-releases#11919 <https://github.com/obsidianmd/obsidian-releases/pull/11919> (automated checks pass; awaiting human review). I deliberately renamed it (obsidian-mcp-connector) so there's no confusion with your repo, and I'm happy to make the relationship with the original project explicit in the fork's README if you'd like specific wording. If you're still around and ever feel like coordinating — whether that's a small note in your README, co-maintaining, or anything else — I'm very open to it. Equally, if you'd rather I just keep going independently and don't need to hear more about this, that's absolutely fine too; please feel free to close this issue. No rush, no expectations. Just wanted the door to be open. istefox — Reply to this email directly, view it on GitHub <#79?email_source=notifications&email_token=AFSOQBCV43FOY3ME7GQCHTD4W54LPA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBTGAZTANJVGUZTRJTSMVQXG33OU5WWK3TUNFXW5JLFOZSW45FMMZXW65DFOJPWG3DJMNVQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSOQBHWLCKP5N6B4D3FETT4W54LPAVCNFSM6AAAAACYBAKRSWVHI2DSMVQWIX3LMV43ASLTON2WKOZUGMYDGMBVGU2TGOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[istefox]

Yes, absolutely — I'd love to be part of a maintainers team. Thank you for proposing it; sharing the work across a few people is genuinely the healthier setup, and I think the project deserves it.

Here's what I'd like to offer concretely, so this isn't just a "yes in principle":

A ready-made next release for upstream. Over the past months I've been carrying the project forward on a fork (istefox/obsidian-mcp-connector, currently at 0.3.4) and most of the work is things that would benefit every existing obsidian-mcp-tools user, regardless of what we decide about the fork itself. If you're open to it, I'd be happy to prepare a PR (or a series of them, however you prefer to review) that lands this work back here, so your current users get the fixes without needing to install anything different. In short, the natural home for this work is your repo, and I'd rather get it to your users than maintain a parallel plugin.

The main pieces already implemented and tested:

• SDK modernization. Migrated from the deprecated Server API to McpServer on @modelcontextprotocol/sdk 1.29.0, with a single ToolRegistry registration path that handles boolean coercion, error formatting, and logging uniformly.
• Plugin-review compliance. Addressed the items flagged by the Obsidian community-plugin reviewer bot.
• Command execution (issue [FEATURE] Command Execution Support #29). New execute_obsidian_command tool, gated by a per-vault allowlist, deny-by-default, rate-limited, with a two-phase mutex around settings persistence and a regression test for concurrent loadData/saveData. Threat model and design in docs/design/issue-29-command-execution.md. A companion list_obsidian_commands covers the read-only case.
• Native binary content for get_vault_file (issue [FEATURE] Obsidian MCP getVaultFile() cannot fetch Audio #59). Images and audio returned as MCP native content where supported, text fallback otherwise.
• API URL / schema fixes. Addresses the additionalProperties: {} + trailing-slash regressions affecting Letta and similar clients (Tool inputSchema uses additionalProperties: {} which breaks Letta Cloud validation #63, [BUG] Trailing slash on paths causes HTTP error 500 #37).
• Svelte 5 upgrade (with the bundler patch documented in the repo) and new test infrastructure for the plugin: a synthetic obsidian module plus mocks for FileSystemAdapter, Modal, and the svelte mount/unmount recorders, enabling bun test coverage for the settings-lock and command-permission paths.
• CLAUDE.md in the repo root, documenting invariants, data flow, and gotchas for both humans and AI agents.

Nothing here is presented as "take it all." Consider it a menu — you (and whoever else joins the team) pick what you want, how you want it shaped, and what gets left behind.

A few light questions so I can align with however you want to run things:

1. Who else is joining? You mentioned a couple of other inquiries — happy to coordinate with them on this thread or wherever you'd like to collect the conversation (Discord, a draft org, etc.).
2. How would you like to organize the team? Lead maintainer + co-maintainers, rotating triage, lazy consensus on non-trivial changes — any shape is fine with me. I just want to follow your lead on structure.
3. Preferred response cadence to issue authors and PRs? Useful for me to know what we want to commit to publicly, so we don't set an expectation we can't hold.

On the community-plugin PR I have open at obsidianmd/obsidian-releases#11919: I opened it assuming the original project was fully dormant. With you back in the loop, the much better outcome is to channel this work through your existing plugin listing and keep users in one place — so I'm very happy to pause or repurpose that submission in favor of a joint upstream release here.

Whatever pace and shape work best for you, I'm in. Just say the word on how you'd like to start.

[istefox]

@jacksteamdev — quick status audit on the 25 upstream issues currently open, so you have a clean view of what's already addressed in the fork and what's left for a joint next release. (Counts are as of 2026-04-22.)

Fixed and credited in the 0.3.x CHANGELOG.md — 22 issues

Issue	Short description	Shipped in
#26	Platform override for binary selection (OBSIDIAN_SERVER_PLATFORM)	0.3.0
#28	Install MCP server outside the vault (new default)	0.3.0
#29	Command execution (feature set + allowlist + audit log)	0.3.0
#30	patch_vault_file heading-path corruption	0.3.0
#31	Arch-Linux installer failure	0.3.0
#35	Non-Claude-Desktop client docs	0.3.0
#36	iCloud / symlink path de-duplication	0.3.0
#37	Trailing-slash → 500 on list_vault_files	0.3.3
#39	search_vault_smart missing Content-Type: application/json	0.3.0
#40	Custom HTTP/HTTPS ports via env	0.3.0
#41	execute_template on tagless YAML	0.3.0
#59	Native MCP audio/image content for get_vault_file	0.3.0 + 0.3.4
#60	Documentation for Claude Code	0.3.0
#61	OBSIDIAN_DISABLED_TOOLS env + UI	0.3.0
#62	limit parameter on search_vault_simple	0.3.0
#63	additionalProperties: {} stripped for strict validators	0.3.3
#66	OBSIDIAN_API_URL env alias	0.3.3
#67	Port hardcoded to 27124	0.3.0
#68	Local REST API v3.4.x compatibility (optional root fields)	0.3.0
#71	patch_vault_file corruption on nested headings	0.3.0
#77	delete_active_file invalid schema for openai-codex	0.3.0
#78	patch_vault_file with non-ASCII heading names	0.3.0

Nine of these had been silently fixed during the 0.3.0 cut and were only credited retroactively after an audit pass — the fixes themselves have been in production since 2026-04-11.

Fix shipped, awaiting reporter confirmation — 2 issues

• [BUG] 404 Error and Schema Issues #33 — Gemini CLI 404 + schema errors. Root cause maps to delete_active_file tool has invalid schema for openai-codex (openclaw) #77 (explicit properties key), [BUG] the search smart tool fails. MCP log shows that POST /search/smart gives a 404. #39 (Content-Type) and the SDK 1.29.0 McpServer migration. Test request posted to @felores.
• [BUG] Error when trying to run the server with MCP SuperAssistant #38 — MCP SuperAssistant ENOENT on iCloud vault path. Subsumed by [FEATURE] Ability to install MCP server outside of vault #28 + [BUG] Download Path contains duplicate /home/<user> #36. Test request posted to @FlatulentFowl.

Not yet addressed — 1 issue

• [BUG] #27 — Installer fails on a vault hosted on an NFS-mapped Windows drive with Failed to resolve symlink. Genuinely untouched; edge case with no reporter activity since 2025-07 and a repro setup I don't have access to.

Concretely

Of the 25 open issues, 22 are fixed-and-merged on the fork, 2 are probable fixes awaiting reporter confirmation, and 1 is a genuine outstanding edge case. I'm happy to translate any of these into staged PRs against this repo — one sweep, or batched by area (installer / schema-and-validation / command execution / docs), or issue-by-issue — whichever you and the other joining maintainers would find easiest to review.

[juicyjonny]

@istefox thank you for your fork! Was just in time too. I just migrated from Notion to Obsidian and needed an MCP server to fix a lot of my organization. I was able to get your fork working when installing from BRAT. I had issues with installing this one.

+1 vote on the merge please!

[istefox]

Thanks @juicyjonny — really glad the fork helped you land on your feet during the Notion → Obsidian switch. Good timing on your side and good motivation on ours.

Your +1 is noted and genuinely useful as a usage signal. If @jacksteamdev is still weighing the maintainership-team proposal upstream, accounts like yours — real-world vaults where the fork is the only install path that works out-of-the-box — are exactly the kind of data that makes the case for folding this work back into the upstream repo rather than maintaining a parallel plugin.

In the meantime: if you run into anything broken on the fork, please open an issue at https://github.com/istefox/obsidian-mcp-connector/issues — turnaround is usually quick. And welcome to Obsidian.

[jacksteamdev]

After some thought, I've decided to make this project officially unmaintained. I'm not using Obsidian currently, so I don't get much ROI for maintaining this project. Given the recent rise in AI supply chain attacks, the local executable this plugin uses to support MCP is too much of a security liability. When I designed this plugin the MCP spec only supported stdio, but later versions of the spec support MCP over HTTP. I don't want to take responsibility for this type of attack vector. My recommendation for current users is to find a plugin that uses MCP over HTTP, ideally HTTPS, which would greatly simplify the implementation and eliminate the need for downloading an external executable. I'll be happy to add a link to the readme for any project that implements MCP over HTTP, as long as that plugin has passed the official Obsidian review process and is published to the Obsidian plugin store. Please DM me on Discord with a link to the merged Obsidian plugin PR and make a PR to this repo updating the readme.

…

On Fri, Apr 24, 2026, 5:37 AM steffer ***@***.***> wrote: *istefox* left a comment (jacksteamdev/obsidian-mcp-tools#79) <#79 (comment)> Thanks @juicyjonny <https://github.com/juicyjonny> — really glad the fork helped you land on your feet during the Notion → Obsidian switch. Good timing on your side and good motivation on ours. Your +1 is noted and genuinely useful as a usage signal. If @jacksteamdev <https://github.com/jacksteamdev> is still weighing the maintainership-team proposal upstream, accounts like yours — real-world vaults where the fork is the only install path that works out-of-the-box — are exactly the kind of data that makes the case for folding this work back into the upstream repo rather than maintaining a parallel plugin. In the meantime: if you run into anything broken on the fork, please open an issue at https://github.com/istefox/obsidian-mcp-connector/issues — turnaround is usually quick. And welcome to Obsidian. — Reply to this email directly, view it on GitHub <#79 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSOQBD4YMB77TATSMQMT5D4XM7VXAVCNFSM6AAAAACYBAKRSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMJSGUZDKOBVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[istefox]

Thank you for the clarity on direction and for the specific criteria. The supply-chain concern around shipping platform binaries is a legitimate one — not something I want to argue with. Your push toward HTTP-based transports where the spec now supports them is technically sound and aligned with where I was already heading.

Concrete state of the fork so it's verifiable, not just asserted:

• istefox/obsidian-mcp-connector — 0.3.0 through 0.3.5 shipped across the last two months, 23 of the 26 open upstream issues resolved (with individual comments on each)
• Community store submission obsidianmd/obsidian-releases#11919 — automated lint cleared after the 0.3.2 pass, awaiting human review
• Own plugin id (mcp-tools-istefox), coexists cleanly with yours

The HTTP pivot isn't a "we'll consider it" — design and plan for it are already committed on feat/http-embedded:

• Design doc: docs/design/2026-04-24-http-embedded-design.md
• Phase 1 implementation plan: docs/plans/0.4.0-phase-1-infrastructure.md

Target architecture for 0.4.0: the plugin hosts the MCP server in-process, exposing Streamable HTTP (spec 2025-06-18) on 127.0.0.1:27200. No binary is shipped from this repo. Local REST API becomes optional (direct use of app.vault.* and app.workspace.*). Native semantic search via on-device MiniLM embeddings.

One honest note on the client side: Claude Desktop still doesn't speak HTTP transport natively (see anthropics/claude-code#30327), so 0.4.0 ships guidance for users to bridge via npx mcp-remote — the official Anthropic-maintained shim. Other clients (Claude Code, Cursor, Cline, Continue, VS Code) connect to the HTTP endpoint directly. Either way, nothing compiled ships from obsidian-mcp-connector.

I'd like to take this on as the continuation maintainer — not a transitional caretaker. Happy to follow up on Discord as you suggested; I'll ping you once the community store listing goes live, together with a PR to your README.