Skip to main content
Glama
ToKiDoO

Advanced Obsidian MCP Server

by ToKiDoO

obsidian_patch_file

Insert content into existing Obsidian notes relative to headings, block references, or frontmatter fields using append, prepend, or replace operations.

Instructions

Insert content into an existing note relative to a heading, block reference, or frontmatter field.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filepathYesPath to the file (relative to vault root)
operationYesOperation to perform (append, prepend, or replace)
target_typeYesType of target to patch
targetYesTarget identifier (heading path, block reference, or frontmatter field)
contentYesContent to insert

Implementation Reference

  • The run_tool method of PatchContentToolHandler, which validates input arguments and calls the underlying api.patch_content to perform the patching operation, then returns a success message.
    def run_tool(self, args: dict) -> Sequence[TextContent | ImageContent | EmbeddedResource]:
        if not all(k in args for k in ["filepath", "operation", "target_type", "target", "content"]):
            raise RuntimeError("filepath, operation, target_type, target and content arguments required")
    
        api.patch_content(
            args.get("filepath", ""),
            args.get("operation", ""),
            args.get("target_type", ""),
            args.get("target", ""),
            args.get("content", "")
        )
    
        return [
            TextContent(
                type="text",
                text=f"Successfully patched content in {args['filepath']}"
            )
        ]
  • The get_tool_description method defining the tool's name, description, and input schema for validation.
    def get_tool_description(self):
        return Tool(
            name=self.name,
            description="Insert content into an existing note relative to a heading, block reference, or frontmatter field.",
            inputSchema={
                "type": "object",
                "properties": {
                    "filepath": {
                        "type": "string",
                        "description": "Path to the file (relative to vault root)",
                        "format": "path"
                    },
                    "operation": {
                        "type": "string",
                        "description": "Operation to perform (append, prepend, or replace)",
                        "enum": ["append", "prepend", "replace"]
                    },
                    "target_type": {
                        "type": "string",
                        "description": "Type of target to patch",
                        "enum": ["heading", "block", "frontmatter"]
                    },
                    "target": {
                        "type": "string", 
                        "description": "Target identifier (heading path, block reference, or frontmatter field)"
                    },
                    "content": {
                        "type": "string",
                        "description": "Content to insert"
                    }
                },
                "required": ["filepath", "operation", "target_type", "target", "content"]
            }
        )
  • TOOL_MAPPING dictionary that maps the tool name TOOL_PATCH_CONTENT ("obsidian_patch_file") to its PatchContentToolHandler class, used for registration.
    TOOL_MAPPING = {
        tools.TOOL_LIST_FILES_IN_DIR: tools.ListFilesInDirToolHandler,
        tools.TOOL_SIMPLE_SEARCH: tools.SearchToolHandler,
        tools.TOOL_PATCH_CONTENT: tools.PatchContentToolHandler,
        tools.TOOL_PUT_CONTENT: tools.PutContentToolHandler,
        tools.TOOL_APPEND_CONTENT: tools.AppendContentToolHandler,
        tools.TOOL_DELETE_FILE: tools.DeleteFileToolHandler,
        tools.TOOL_COMPLEX_SEARCH: tools.ComplexSearchToolHandler,
        tools.TOOL_BATCH_GET_FILES: tools.BatchGetFilesToolHandler,
        tools.TOOL_PERIODIC_NOTES: tools.PeriodicNotesToolHandler,
        tools.TOOL_RECENT_PERIODIC_NOTES: tools.RecentPeriodicNotesToolHandler,
        tools.TOOL_RECENT_CHANGES: tools.RecentChangesToolHandler,
        tools.TOOL_UNDERSTAND_VAULT: tools.UnderstandVaultToolHandler,
        tools.TOOL_GET_ACTIVE_NOTE: tools.GetActiveNoteToolHandler,
        tools.TOOL_OPEN_FILES: tools.OpenFilesToolHandler,
        tools.TOOL_LIST_COMMANDS: tools.ListCommandsToolHandler,
        tools.TOOL_EXECUTE_COMMANDS: tools.ExecuteCommandsToolHandler,
    }
  • The core Obsidian API client method that performs the HTTP PATCH request to patch content in a file relative to a target (heading/block/frontmatter) using specific headers.
    def patch_content(self, filepath: str, operation: str, target_type: str, target: str, content: str) -> Any:
        url = f"{self.get_base_url()}/vault/{filepath}"
        
        headers = self._get_headers() | {
            'Content-Type': 'text/markdown',
            'Operation': operation,
            'Target-Type': target_type,
            'Target': urllib.parse.quote(target)
        }
        
        def call_fn():
            response = requests.patch(url, headers=headers, data=content, verify=self.verify_ssl, timeout=self.timeout)
            response.raise_for_status()
            return None
    
        return self._safe_call(call_fn)
  • Constant defining the tool name "obsidian_patch_file" used throughout the codebase.
    TOOL_PATCH_CONTENT = "obsidian_patch_file"
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this modifies files permanently, requires specific permissions, handles errors, or has any side effects. For a file modification tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that's perfectly front-loaded with all essential information. No wasted words, no unnecessary elaboration - every word earns its place in conveying the tool's core functionality efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a file modification tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It explains what the tool does but not how it behaves, what it returns, or potential consequences. The agent would need to guess about error handling, file locking, or whether changes are reversible.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'heading, block reference, or frontmatter field' which aligns with target_type enum values but doesn't provide additional context about parameter interactions or usage patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Insert content'), target resource ('existing note'), and positioning method ('relative to a heading, block reference, or frontmatter field'). It distinguishes from sibling tools like obsidian_append_to_file by specifying targeted insertion rather than simple appending.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like obsidian_append_to_file or obsidian_put_file. The description implies usage for targeted content insertion but doesn't specify scenarios, prerequisites, or exclusions that would help an agent choose between similar tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ToKiDoO/mcp-obsidian-advanced'

If you have feedback or need assistance with the MCP directory API, please join our Discord server