Skip to main content
Glama
pvliesdonk

markdown-vault-mcp

by pvliesdonk

Note Diff

get_diff
Read-onlyIdempotent

Compare a note's current version to a previous commit or timestamp. Returns a unified diff for text files or a summary for binary attachments.

Instructions

Return the diff of a note between a reference point and HEAD.

Only available for git-backed vaults. Exactly one of 'since_sha' or 'since_timestamp' must be provided. Use 'get_history' first to find commit SHAs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesVault-relative path of the note or attachment to diff (e.g. "notes/alpha.md" or "assets/diagram.png"). May be a `.md` note or a configured attachment extension (png, pdf, svg, …). A binary attachment returns a `--stat` size/rename summary instead of a full unified patch; a text attachment (e.g. `.svg`, `.csv`) returns a full unified diff. `.md` notes are unchanged. An unsupported extension is rejected.
limitNoWhen per_commit=True, cap the number of intervening commits returned to the `limit` most recent ones. Clamped to [1, 100]. Defaults to null (unbounded — still bounded by the underlying since..HEAD range). Ignored when per_commit=False. Useful for keeping per-commit responses within context budgets when auditing long histories.
since_shaNoA commit SHA (full or abbreviated, at least 4 hex digits) to diff from. Mutually exclusive with since_timestamp.
per_commitNoWhen False (default), return a single unified diff from the reference point to HEAD. When True, return one diff per intervening commit.
since_timestampNoISO 8601 datetime string, resolved via `git rev-list --before=<ts> -1 HEAD` to the most recent commit at or before that instant. Boundary is **inclusive**: a commit whose committer date equals since_timestamp IS the resolved ref. Mutually exclusive with since_sha.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint as true, so safety is clear. Description adds behavioral details: supported vault types, binary vs text handling, and the mutual exclusivity constraint. Could be slightly more detailed on return value shape, but helpful 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.

Conciseness5/5

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

Four sentences, front-loaded with core purpose, then conditions and advice. No redundant words or repetition. Efficient and well-structured.

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 presence of an output schema (indicated), rich input schema descriptions, and annotations, the description is complete. It covers prerequisites, parameter requirements, behavioral notes, and references related tools. No gaps identified.

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?

Schema coverage is 100% with detailed descriptions for all 5 parameters. The description adds value by restating the mutual exclusivity of since_sha and since_timestamp and noting binary attachment behavior. While schema already covers details, the description reinforces key constraints.

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?

Clearly states the tool returns the diff of a note between a reference point and HEAD. Distinguishes from siblings like 'get_history' (which returns commit history) and 'read' (which returns content). The resource and action are specific.

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

Usage Guidelines5/5

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

Explicitly states prerequisite ('only available for git-backed vaults'), parameter requirement ('exactly one of since_sha or since_timestamp'), and references sibling tool ('Use get_history first to find commit SHAs'). Provides clear when-to-use and when-not-to-use context.

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/pvliesdonk/markdown-vault-mcp'

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