Skip to main content
Glama

patch_vault

Correct or extend an existing vault item by updating frontmatter fields such as tags, status, and relations without rewriting the whole file; updated_at is bumped automatically.

Instructions

Patch frontmatter fields on an existing vault item. updated_at is always bumped.

Use this to correct or extend an existing item — e.g. add/remove relations, update tags, change status — without rewriting the whole file.

Workflow:

  1. Call read_vault(path) to get the current content.

  2. Parse the fields you want to change and construct their new values in full (e.g. the complete new relations list, not just the items to add).

  3. Call patch_vault(path, updates={...}) with only the fields that changed.

Args: path: 8-character hex UID (e.g. "0b74b77c"), absolute path, or path relative to vault_root (e.g. "notes/my-note.md"). Prefer the UID when you have it — no lookup call is needed. updates: Dict of frontmatter fields to overwrite. Pass complete new values. Common uses: relations: [{uid: "a1b2c3d4", type: "belongs-to"}, ...] tags: ["tag-a", "tag-b"] status: "done" summary: "Updated summary." Do NOT put the body here — 'body' is not a frontmatter field. A 'body' key in updates is rerouted to the body argument and a warning is returned; a null value there clears the body. Any stale 'body' key already in the file's frontmatter is stripped on every patch. body: If provided, replaces the full body text. Always pass new body text here, never inside updates. Pass "" to clear it.

Returns {uid, path, type, title, ...}, plus tag_warnings when a tag names a project/entity/topic (belongs as a relation) or repeats the node's own type or subtype. The patch has already happened; surface the warning and offer the fix. Other warnings, all of which also arrive after the write: relation_warnings (unknown relation type), has_asset_warnings (unknown scheme or a missing scheme field in has_asset), and field_warnings (a field the patch touched now breaks its type's required fields or enum; a change to type or subtype checks the whole node).

Input Schema

NameRequiredDescriptionDefault
bodyNo
pathYes
updatesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discloses key behavior: updated_at is always bumped, body keys in updates are rerouted or clear the body, stale body frontmatter is stripped, and warnings arrive after the write has already happened. It also explains the warning categories and that the caller should surface them.

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 and front-loaded with purpose, workflow, args, and returns. It is somewhat long, especially the warning catalog, but nearly all details are useful given the absence of annotations and schema descriptions.

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?

For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is complete enough to invoke correctly. It covers prerequisites, argument semantics, side effects, body handling, and return/warning behavior.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate, and it does: path accepts UID, absolute path, or vault-relative path with a preference for UID; updates requires complete new values and examples; body replaces full body text and must not be passed inside updates.

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 states a specific verb and resource: patch frontmatter fields on an existing vault item. It also distinguishes itself from a full-file write by saying it works without rewriting the whole file.

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?

It clearly says to use this for correcting or extending an existing item, gives examples, and supplies a read-then-patch workflow. It lacks explicit naming of when to prefer write_vault or other alternatives, so it falls short of full when/when-not guidance.

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