edit-note fails with "Invalid discriminator value" for all operation types

[mulie-og]

Bug: edit-note fails with "Invalid discriminator value" for all operation types
Repository: https://github.com/StevenStavrakis/obsidian-mcp
Tool affected: edit-note
Severity: High — tool is completely non-functional; blocks all in-place note editing

Description
The edit-note tool throws MCP error -32602: Invalid arguments: Invalid discriminator value for every operation type (replace, append, prepend). Since all three valid operation values produce this error, the tool is entirely unusable. The error message itself is contradictory — it reports that valid values like replace are invalid, even though replace is explicitly listed in the expected set.

Steps to Reproduce
Call edit-note with any valid operation value:
json{
"vault": "my-vault",
"filename": "test-note.md",
"folder": "some-folder",
"operation": "replace",
"content": "Updated content here"
}
Also tested with:
json{ "operation": "append", "content": "appended text" }
{ "operation": "prepend", "content": "prepended text" }
All three produce the same error.

Actual Behavior
MCP error -32602: MCP error -32602: Invalid arguments: Invalid discriminator value.
Expected 'delete' | 'append' | 'prepend' | 'replace'
This error is returned regardless of which operation value is passed — including values that are explicitly listed as expected by the error message itself (e.g., replace).

Expected Behavior
edit-note with operation: "replace" should replace the full note content.
edit-note with operation: "append" should append content to the end of the note.
edit-note with operation: "prepend" should prepend content to the beginning of the note.

Environment

Client: Claude Desktop (Cowork mode)
OS: Windows 11
Vault location: OneDrive (C:\Users...\OneDrive\Documents\Obsidian Data...)
Other tools tested (working): create-note, read-note, delete-note, search-vault — all function correctly

Workaround
Delete the target note with delete-note (moves to Obsidian trash, not permanent), then recreate it with create-note containing the updated full content. This is destructive and loses any Obsidian link backlinks to the original file, but functionally achieves a replace operation.

Additional Notes
The tool's parameter schema in the MCP manifest is defined as {"properties": {}, "type": "object"} — an empty schema. It's possible the server-side discriminated union validation is not correctly receiving or parsing the operation field when called through the MCP protocol, causing it to treat the value as undefined/null even when explicitly provided. Might be worth checking whether the zod/schema validation on the server side is correctly mapped to the incoming JSON body structure.

Reported via Claude Desktop · 2026-03-10

[builtbybrayne]

This is quite a severe issue problem.

Since adding this MCP, my agent first fell back to a delete-recreate process, which I then replaced with a blue-green workflow to allow it to check for data loss. But backlinks are broken either way. Which means my vault is now littered with broken links.

Rather problematic when note editing is a major use-case!

fwiw, I explored a number of possible fixes, though none are palatable if insistent on a single edit-note method. The most sensible proposal - to my eyes - is to split the tool into separate tools (append-to-note, replace-in-note, delete-from-note). This sidesteps the schema generation issue entirely but changes the tool's API surface. edit-note can of course be left in and deprecated for agents that do ingest it ok.

Personally, I don't think having multiple tools like this is a problem when the target consumer is an AI agent anyway.

[erikhuggers]

PR #41 merged a fix for this on March 18 but npm is still on 1.0.6 (7 months old). Could you publish 1.0.7? This is blocking all edit-note operations for managed connector users.

[efrv]

I ran into the same issue and dug into the code to figure out what's going on.

What's happening:

The createSchemaHandler function in src/utils/schema.ts converts Zod schemas to JSON Schema for MCP clients. It expects every schema to have type, properties, and required at the top level. But edit-note is the only tool that uses z.discriminatedUnion(), which produces { anyOf: [...] } instead — no type, no properties at the top.

The code just silently falls back to empty defaults, so MCP clients end up seeing { type: "object", properties: {} } — basically no schema at all. Meanwhile the server still validates with the real Zod schema internally, which is why the discriminator error fires no matter what you pass.

Every other tool uses flat z.object() so they work fine.

About PR #41: I saw it was closed — the approach of flattening union variants into a single schema makes sense, especially since some clients like Claude API reject top-level anyOf/oneOf. Happy to submit a fresh PR with a fix if thats welcome.