Skip to main content
Glama
sunub

Obsidian MCP Server

Write Obsidian Property

write_property

Adds or updates properties in an Obsidian markdown file's frontmatter to apply generated metadata such as title, date, tags, and summary.

Instructions

Description: Adds or updates properties within the frontmatter section at the top of a specified Obsidian markdown file. This tool is primarily used to apply metadata generated by the 'generate_property' tool to an actual file.

Parameters:

  • filePath (string, required): The path to the target markdown file to which properties will be added or updated. Example: "my-first-post.md"

  • properties (object, required): A JSON object containing the key-value pairs to be written to the file's frontmatter. If a property with the same key already exists in the file, it will be overwritten with the new value.

Example:

JSON { "title": "Optimizing I/O Handling in a Serverless Environment", "date": "2025-04-03", "tags": ["serverless", "optimization"], "summary": "A case study on optimizing I/O in a serverless environment by benchmarking Promise.all and Workers.", "completed": true }

Return Value:

Upon successful execution, it returns a JSON object containing the status, a confirmation message, and the property object that was applied to the file.

Example:

JSON { "status": "success", "message": "Successfully updated properties for my-first-post.md", "properties": { "title": "Optimizing I/O Handling in a Serverless Environment", "date": "2025-04-03", "tags": ["serverless", "optimization"], "summary": "A case study on optimizing I/O in a serverless environment by benchmarking Promise.all and Workers.", "completed": true } }

Dependencies & Requirements:

  • Input Data: The properties parameter should typically be the JSON object output from the 'generate_property' tool.

  • Environment Setup: The absolute path to the user's Obsidian Vault must be correctly set as an environment variable.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filePathYesPath to the target markdown file within the Obsidian vault
propertiesYesKey-value pairs to be written to the file's frontmatter
quietNoIf true, suppresses non-error output messages. Default is false.

Implementation Reference

  • The main execute function for the write_property tool. It gets the vault manager, calls writeDocument with the file path and properties, and returns success/failure results.
    export const execute = async (
    	params: ObsidianPropertyParams,
    ): Promise<CallToolResult> => {
    	const vaultDirPath = state.vaultPath;
    	if (!vaultDirPath) {
    		return createToolError(
    			"VAULT_DIR_PATH is not set. Cannot write properties to file.",
    			"Set the VAULT_DIR_PATH environment variable to your Obsidian vault path.",
    		);
    	}
    
    	let vaultManager = null;
    	try {
    		vaultManager = getGlobalVaultManager();
    	} catch (e) {
    		return createToolError((e as Error).message);
    	}
    
    	try {
    		await vaultManager.writeDocument(params.filePath, params.properties);
    
    		if (params.quiet) {
    			return {
    				isError: false,
    				content: [
    					{ type: "text", text: JSON.stringify({ status: "success" }) },
    				],
    			};
    		}
    
    		return {
    			isError: false,
    			content: [
    				{
    					type: "text",
    					text: JSON.stringify(
    						{
    							status: "success",
    							message: `Successfully updated properties for ${params.filePath}`,
    							properties: params.properties,
    						},
    						null,
    						2,
    					),
    				},
    			],
    		};
    	} catch (error) {
    		if (error instanceof VaultPathError) {
    			return createToolError(
    				"filePath is outside VAULT_DIR_PATH. Writing outside the vault is blocked.",
    				`Use a filePath inside VAULT_DIR_PATH ("${error.vaultPath}"). Received filePath: "${error.inputPath}"`,
    			);
    		}
    
    		return createToolError(
    			(error as Error).message || "An unknown error occurred.",
    		);
    	}
    };
  • The writeDocument method on VaultManager that resolves the path, reads existing content, merges frontmatter via gray-matter's stringify, writes the file, and re-indexes it.
    public async writeDocument(
    	fullPath: string,
    	frontmatter: Record<string, unknown>,
    ): Promise<void> {
    	const resolvedPath = this.resolvePathForWrite(fullPath);
    
    	await this.ioSemaphore.acquire();
    	try {
    		const content = (await this.readDocumentContent(resolvedPath)) || "";
    		const newDocument = matter.stringify(content, frontmatter);
    		await writeFile(resolvedPath, newDocument, "utf8");
    	} finally {
    		this.ioSemaphore.release();
    	}
    	await this.upsertDocument(resolvedPath);
    }
  • Zod schema defining the input validation for write_property: filePath (required), properties (object with optional fields like title, tags, date, etc.), and quiet mode flag.
    import { z } from "zod";
    
    // input properties
    const obsidianCssClassesProperty = z
    	.array(z.string())
    	.describe("List of CSS classes associated with the document");
    const obsidianTagsProperty = z
    	.array(z.string())
    	.describe("List of tags associated with the document");
    const obsidianTitleProperty = z.string().describe("Title of the document");
    const obsidianDateProperty = z
    	.string()
    	.describe("Creation date of the document in ISO 8601 format");
    const obsidianSummaryProperty = z
    	.string()
    	.describe("Brief summary or abstract of the document");
    const obsidianSlugProperty = z
    	.string()
    	.describe("URL-friendly identifier for the document");
    const obsidianCategoryProperty = z
    	.string()
    	.describe("Category or classification of the document");
    const obsidianCompletedProperty = z
    	.boolean()
    	.describe("Indicates whether a task or item is completed");
    const quiteMode = z
    	.boolean()
    	.default(true)
    	.describe("If true, suppresses non-error output messages. Default is false.");
    
    const obsidianPropertySchema = z
    	.object({
    		cssclasses: obsidianCssClassesProperty.optional(),
    		tags: obsidianTagsProperty.optional(),
    		title: obsidianTitleProperty.optional(),
    		date: obsidianDateProperty.optional(),
    		summary: obsidianSummaryProperty.optional(),
    		slug: obsidianSlugProperty.optional(),
    		category: obsidianCategoryProperty.optional(),
    		completed: obsidianCompletedProperty.optional(),
    	})
    	.describe("Schema for Obsidian frontmatter properties");
    
    // input schema
    export const obsidianPropertyParamsSchema = z
    	.object({
    		filePath: z
    			.string()
    			.min(1)
    			.describe("Path to the target markdown file within the Obsidian vault"),
    		properties: obsidianPropertySchema.describe(
    			"Key-value pairs to be written to the file's frontmatter",
    		),
    		quiet: quiteMode.optional(),
    	})
    	.describe("Parameters for writing properties to an Obsidian markdown file");
  • The register function that binds the tool name, schema, annotations, and execute handler to the MCP server.
    export const register = (mcpServer: McpServer) => {
    	mcpServer.registerTool(
    		name,
    		{
    			title: annotations.title || name,
    			description: description,
    			inputSchema: obsidianPropertyParamsSchema.shape,
    			annotations: annotations,
    		},
    		execute,
    	);
    };
  • Import and export of WriteObsidianPropertyTool from the centralized tools barrel file.
    import WriteObsidianPropertyTool from "./write_property/index.js";
    
    export default {
    	ObsidianVaultTool,
    	GenerateObsidianVaultPropertiesTool,
    	WriteObsidianPropertyTool,
    	CreateDocumentWithPropertyTool,
    	OrganizeAttachmentsTool,
    };
Behavior4/5

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

The description reveals that properties are added or updated, with existing keys being overwritten, and returns a success object with status, message, and applied properties. Annotations provide only 'openWorldHint: true' which implies side effects but no contradictions. The description adds behavioral context beyond annotations.

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

Conciseness4/5

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

The description is well-structured with clear sections (Description, Parameters, Return Value, Dependencies). It includes examples that are helpful, though slightly verbose. Every sentence adds value, but could be slightly more concise.

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

Completeness5/5

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

Given the tool's complexity (3 params, nested object, no output schema), the description fully covers what the agent needs: purpose, parameters with examples, return value format, dependencies, and environment requirements. It is comprehensive for correct usage.

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

Parameters4/5

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

Input schema has 100% coverage with descriptions for all parameters. The description provides examples for both parameters, explains that 'properties' should typically be the output of 'generate_property', and clarifies the overwriting behavior. This adds meaning beyond the schema.

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 tool adds or updates properties in frontmatter of an Obsidian markdown file, using a specific verb ('adds or updates') and resource ('frontmatter'). It distinguishes from siblings like 'create_document_with_properties' (creates documents) and 'generate_property' (generates properties).

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

Usage Guidelines4/5

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

The description explicitly says the tool is 'primarily used to apply metadata generated by the 'generate_property' tool', providing a clear use case. It also mentions dependencies like environment setup, but does not explicitly state when not to use it or list alternative tools, though sibling distinction is implicit.

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/sunub/obsidian-mcp-server'

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